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(54) Decision support system for the nnanagement of an agile supply chain 



(57) A decision support system for the management 
of an agile supply chain that provides an architecture 
including a server side and a client side. TTie server side 
includes a decision support system database that inter- 
faces with model engine that perfonms analysts of the 
data to support planning decteions. The server side 
includes a server manager that coordinates requests tor 
service and information. The client side irK^ludes deci- 
sion frames that present the various view points availa- 
ble in the system to the users. A frame manager 
coordinates the requests from dedston sipport frames 
to access the needed data and modete. The dedston 
support franies provide a view into supply chain and 
integrate analytica] models respor^e to the view point 
of a business process such as demarxi management 
The frames indude a sipply management frame, a 
demand management frame, a vendor managed 
replenislvnent frame, a Planning. Sales and Inventory 
planning frame and a distribution network design frama 
The model engine indudes a conponent procurement 
poficy de^elopnient nrnxjule. a finished goods dtstrSxj- 
tion network design module, an a^egate production 
planning module, a finished goods inventory manage- 
ment module, a sales forecasting and planning module, 
a market data analysis module, a venctor managed 
replenishment module and various utifities such as 



generic linear programming solvers and statistical anal- 
ysis routines. The system also indudes a demand and 
supply recondliation process reoondling production, 
sales and inventory and recondling a top<lown forecast 
with a bottonMjp forecast where an expert based model 
is used for the bottom-up forecast A capacity planning 
process determines the feasbility of a capacity plan 
responsive to supply constraints. A vendor managed 
replenishment process plans inventory replenishnrtent 
analysts and periods responsive to predicted sales and 
supply constraints. A scenario management process 
associated with all frames enables the user to analyze 
(Afferent hypothetical scenarios for comparison of big- 
ness plans. The frame manager indudes a system inte- 
ger and a functional integrator. A database 
nnanagement system manages the supply and mainte- 
nance of information needed by the modeling proc- 
esses through the frame manager. A domain 
management process limits data available to said 
frames respor^e to a user selection. 
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' Description^ ' ....t-io.-' 
BACKGROUND OF THE IhJVErsTTlON 
5 Field of the Invention 

The present invention is directed to a system for si^sporting management decisions associated with manufacturing 
of service supply chains that span from a point of aeation to a point of consumption arxi. more particularly, is directed 
to a system tfiat allows the various decision makers in the supply chain to view the supply chain from their own perspec- 
10 tive. obtain information and evaluate decisions conceming past current and future performance with respect to a 
diverse set of often conflicting goals. 

Description Of The Related Art 

IS Many types of maruifacturing datatsase management and inventory control systems exist today. Each of tfiese sys- 
tems views the process from the narrow viewpoint of the goals of such a system. For example, inv^itory control proc- 
esses tend to determine when the inventory of an item is projected to t>e depleted and when to order goods to prevent 
such depletion. The inventory control process does hot generally take into account the problems associated with avail- 
at>ilrty of materials and machines to satisfy the inventory demand. On the other hand the manufacturing control process 

20 considers the availability problem but does not take into account the effect of a sales promotion that will deplete an 
inventory faster than projected. A marketing department in preparing a sales promotk)n will often not consider the effect 
that promotion will have on availability, inventory and profit margin but tends to focus on sales goals. What is needed is 
a system that will support managers with each of these view points in understanding the effect of the various decisions 
that can be made on the supply chain as a whole both currently and irrto the near futura 

25 

SUMMARY OF THE INVENTION 

It is an object of the present invention to provide a system that allows a decision maker in a supply chain to view 
the chain from their own perspective arxJ understarxj the effect that their decisions will have on the supply chain as a 
30 whole. 

It is arKTther object of the present invention to provide a dtstrbuted arxi layered architecture that alksws the reuse 
of processing resources and data in makir^g diverse different view point decisions concerning a supply chain. 

It is also an object of the present invention to provide a User Interface that projects a view (a Decision Support 
Rame) into the supply chain ttiat takes into account the view point of the partk:ular user, such as a plant mar^ger or 
35 sales manager. 

it is arKSther object of the preiserrt invention to provide quantitative nxxlels and analytical processes to support the 
plans prepared and decisions made from the various supply chain view points such that these resources are cost effec- 
tively provided arxl utilized in across the entire supply chain-wide. 

It is also an object of the present invention to provide a scenario management system in whk;h Scenarios can fc»e 
40 saved, mocfified and data transfOTed t)etween view points or frames. 

It is a further object of the present irNerrtion to allow the user to specify a data donriain that Bn^ 
a particular view point. 

It is an adcfitional object of the present invention to provide a system that will recorKite the demand and supply 
aspects of a supply chain. 

45 It is Still arKTther object of the present invention to aDow the aeation of an integrated production, sates and inventory 

(PSQ plan and provide a projection concerning what is feastole in the production, sales and inventory plan. 

Kisanobjectof thepresenttrventiontoalkTwthemarujfacturerorverxkvto , 

for a customer that integrates all informatk)n about a product including current past and projected future sales and 

inventory, into a feasft)le replenishment plan. 
50 It is a further object of tfie present inventk>n to provide a planning process that reconciles top down and txittom up 

projections. 

It is an object of the present inverrtion to provide eoq^ based nvxJels that alk^ points 
including a bottom up view point 

It is also an object of tf^ present iriveritkxi to operate in an interactive arKl dyriar^ 
55 dec^ion support to single or a set of users. 

It is also another object of the present invention to maintain overall data consistency and provide performarx^e feed- 
t)ack to users reflecting the impact of locai' decistons on global supply chain perfbrmarx:e. 

The atxive-identified objects can be attained a decision su|)port system for tfie management of agile supply 
chains that provides an architecture including a server side and a dient side. The sender side includes a decision sup- 
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port system dalat>ase that interfaces with one or more model engines ttiat perform analytical processes on the data to*^ ^--vt-t . w 
determine requirements and make prcjectiorts. The server side irn^ludes a server manager that coordinates requests 
for service and information. The client side includes Decision Support Frames that present the various view points avaD- 
at3le in the system to the A frame manager that coordinates the requests from Decision Support Frame (view 
5 points) is provided t]y the system to access the needed data and models. 

These together with other objects and advantages which will be stteequentty apparent reside in the details of con- 
struction and operation as more fully hereinafter descrft>ed and claimed. refererYce being had to the accorrpanying 
drawings forming a part hereof, wherein like numerals ref^ to like parts throughout. 

10 BRIEF DESCRIPTION OF THE DRAWINGS 

Rgure 1 DSS System Architecture in the Context of Manufacturing Supply Chains. 

Figure 2 DSS System Architecture in the Context of Equipment Repair Supply Chains. 

Figure 3 Decision Support Thread. 
IS Rgure 4 The Data Sp^:es in Supply Chain Marragemenl 

Figure 5 Structural Elements in the DSS Datat>ase for the Manufacturing Supply Chain. 

Rgure 6 Structural Elements in tfie DSS Datat)ase for the Equipment Repair Supply Chain. 

Figure 7 Specification of Decision Support Frame. 

Rgure 8 Decision Processes in the Manufacturing Supply Chain. 
20 Figure 9 High Level Model of an Bqupment Repair Supply Chain and the Decision Processes. 

Rgure 10 Process and Data Row Dia^am Legend. 

Figure 1 1 Data Space Associations of the DemarvJ Management Frame. 

Rgure 1 2 Process Row of the Demand Management Frama 

Rgure 1 3 Process Row of Ord^ Fulfillment. 
2S Rgure 14 Data Row for the Demarxi Management Frama 

Figure 15 Data Space Associations of the Production-Sales-Inventory Planning Frame. 

Figure 16 Process Rcw of the Production-Sales-lnventory Planning Firama 

Rgure 17 Data Row for the Production-Sales-lnventory Planning Frame. 

Rgure 18 Data Space Associations of the Supply Management Frame. 
30 Rgure 1 9 Process Row of the Supply Management Frame. 

Figure 20 Data Rcw for the Supply Managenfent Frame. 

Figure 21 Data Row for the Supply Management Frame. 

Rgure 22 Data Space Associations of the Vendor Managed Replenishment Frame. 

Rgure 23 Process Row of the Vendor Managed Replenishnrtent Rama 
35 Rgure 24 Data Row for the Vendor Managed Replenishment Frame. 

Rgure 25 Data Space Associations of the Distribution Network Design Frame. 

Rgure 26 F^rocess Row of the Distrftxition Network Design Frama 

Figure 27 Data Row for the Distribution Network Design Firama 

Figure 28 Seven Modiries and Supply Chain Management 
40 Figure 29 Pareto Analysis for ABC Classfficatk>n. 

Figure 30 Scatter Plot for Sales-VolatHity Ctassificatkm. 

Figure 31 Impact of Sales Promotion. 

Rgure 32 Curve Fitting for Promotion Effect Analysis. 

Rgure 33 System Level Servk;es. the Seven Modules and Model Engine Utilities. 
45 Figure 34 Supply Chain Frame Marker: High Level Architecture. 
Figure 35 High Level Architecture of the System Integrator. 

Figure 36 High level object representatx>n of the ^stem imegrator portion of the frame ni^^ 

Figure 37 High Level Architecture of the Functional Integrator. 

Rgure 38 Data Rcw Dia^am for the Supply Chan Network Configurator. 
so Figure 39 Functk>nalrty in the Domain Manager. 

Rgure 40 Hierarchical Structure of a Scenario. 

Figure 41 Data Rcw Dia^am tor the Performance Simulator. 

Figure 42 User-DSS Interaction Process. 

Rgure 43 Sample Screen from PSI DSS. 
55 Figure 44 Three-tier Application Development Architectura 

Figure 45 DSS Devek)pment Platform Environment 

Figure 46 Generic System Architecture. 

Figure 47 System Architecture in View of the DSS Prototype. 

Figure 48 The Logon Diak)g Box. 
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Figure 49 The Op^ng Screen cyfthe DSS: » .- oi .--^»»T- — - 

Figure 50 User Preferences Selection Dialog Box. 

F^ure 51 The Select Data Domain Form. 

Figure 52 Edit Data Domain Dialog box. 
5 Figure 53 Make Product Domain Dialog Box. 

Figure 54 Save Scenarb Dialog Box. 

Figure 55 Open Scenario Dialog Box. 

Figure 56 Demand Management Bottom Up Forecast Saeen. 

Figure 57 Demand Management Top Down Forecast Saeen. 
10 Figure 58 Promotion Calendar Main D^tay. 

Rgure 59 The Promotion Selection Wizard. 

Figure 60 The Main PSI Frame Form. 

Figure 61 The Options menu choices on the PSI screen. 

Figure 62 PSI Recondiiation Order Dialog Box. 
IS Figure 63 The main capacity checking dialog box - The Options tab. 

Figure 64 The Results tab. 

Figure 65 The Production Resource tatx 

Figure 66 The Key Components tab. 

Figure 67 The Bill of Material tab. 
20 Figure 68 The Alternative Components Tab. 

Figure 69 The Resource Requirement tab. 

Figure 70 Key Component Selection Dialog Box. 

DESCRIPTION OF THE PREFERRED EMBODIMENTTS 

25 

Irrtroduction 

Overview of the DSS Conceptual Architecture 

30 The Decision Support System (DSS) 10 of the present invention (see figure 1) relies on quantitative models arxJ 
data analysis routines to provide decision suf)pon Consider for exarrple the production, sales and inventory (PSI) plan- 
ning process. An architecture to provide such si4)port in accordance with the present invention comprises a library of 
models and routines tfiat are logically linked, regularly updated and maintained. To support the PSI planning process 
for example, one can then empby an appropriate sut>set of models and routines from the library to represent the under- 

35 tying su^y chain abstraction and provide decision support. The present invention assembles the models and routines 
in a flexODle manner, as needed tiy a dec^on makirtg environment to enat)le the DSS 10 to provide ostomized deci- 
sion support with a readOy upgradable arxJ scalable tS>rary. 

Principal Design Elements 

40 

The architecture of the Decision Sipport System (DSS) 10 for a manufacturing sipply chain is shown in figure 1 
and comprises the principal design elements of: a DSS Database 12 with a Database Management System (DBMS) 14 
and Supply Chain lnfonTiatk)n Systems 15, DedsionSupport Frames 16 which provides the various supply chain view 
points, a User Interface 18, a Model Engine 20 including various Model Engine Utilities (processes) 22 and a Supply 
45 Chain Frame Manager 24. The architectiH-e of the DSS 10 in the context of an equipment repair supply chain is illus- 
trated in figure 2. 

SaGent Features 

50 The DSS architecture comprises two basic mode divisions: the Client Mode 30 and the Server Mode 32. These 
modes can be classified with respect to an implementation of the DSS 10 in a supply chain. From a design standpoint 
the Client Mode 30 is tfie portion of the DSS architecture that is specific and therefore customizable to provide decision 
support for any particu^ decision process and decision n^ker. The Server Mode 32, on the other hand, is the kernel 
of tfie DSS architecture that remains largely the same across different applk:atk>ns of the DSS 1 0 within a given supply 

55 chain. Hence, for a given implementatkm of the cfient-server DSS architecture in a supply chain, there will be one 
Server Mode 32 and a number of Ctierrt Modes to provide support for tfie decisk>n p^ 

As shown in figures 1 and 2 the CGent Mode 30 comprises the User tnterfsce 18. the Decision Support Frames 16, 
and the dient version of the Stfsply Chain Frame Manager 24. The Server Mode 32 comprises the Su^^ 
Manager 24, the system level servk:es, ttie Model Engine 20, and the DSS Database 12. The Supply Chain Frame 
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' Manager 24, as a particrpant in both modes, serves to tie the Client and the Server Modes of the architecture together. - 
The dient-server architecture makes the overall design both extensible (new functionality can be added by custom- 
izing a frame In the Client Mode 30) and scalable (new models and routines can be added to the Model Engine 20 in 
the Server Mode 32). Additionally this design is networkable; one can visualize the Server Mode 32 of the DSS 10 
5 hosted by a server workstation in a dient-server network while a rtumber of Cfient Modes 30 of DSS 10 are hosted in 
tfte cfient computers. The layered design of the architecture, in terms of how the principal design elements of the DSS 
1 0 are positioned within the architecture, prcvides a more resilient and stable backtx)ne for decision support. The high 
level design architecture s indep&ident of any computirig and networking platform and hence applicable to a variety of 
environments. 

10 The structure maintains the design of the horizontal layers for its key system elements while its functionality is more 
aligned vertically. The overall DSS 10 interfaces with the Supply Chain Information Systems 15 through the data 
exchanges between these systems and the DSS Datat>ase 12. The DSS 10 has a User Interface 18 to interact with end 
users tfirough interactive and visual data exchange Thus, the main body of the DSS 1 0 indudes the following horizontal 
layers: User Interface 18; Dedston Support Frames 16; Supply Chain Frame Manager 24 (Client and Server); Model 

IS Engine 20; arxi DSS Database 12 . 

Asprevfously mentioned, the atxve layers of the DSS 10 can be partitioned into dient and Server Modes. The sys- 
tem layers within the Client Mode 30 serve an interpretive role t}etween the system data and analytic processing sup- 
port and tile specie end user's dedsfon stpport needs. Those layers under ttie Server Mode 32 contain system 
functionalities common to a diversity of users and dedsion siJ¥)port problems, and usually require more dedicated. 

20 higher performance system processing capabnities. 

To capture and process a user's decision support request, the DSS 1 0 wiD invoke a vertical decision support thread 
40 going through visual objects of a User Interface 18, dec^on fogic and wfmt-if sc^iario manager in a Dedsion Sup- 
port Franrte. Supply Chain Frame Managers, models or analysis routines in the Model Engine 20 arxl appropriate data 
elements in the DSS Datat>ase 12. Anexanpleof adec^onsupportthread40 isshownbythebiKfirectiorialarrcwsin 

25 figure 3. 

Relevant Supply Chains 

The detailed discussion and spedfkations for the Dedsion Support Frames 16 provided in this document are 
30 generic in nature so that the functionality and system features in the resulting DSS 10 can cover dedsion environments 
for a diversity of supply chains. The system specifications and descriptions in th^ document address the two distinctive 
supply chains previously mentioned: I. Manufacturing: Rrdshed goods are produced from raw materials, components. 
arxJ sut>asserri)lies usir)g resources (&g.. humar^ and machines) distributed to the demarKl points. arxJ consumed by 
tfie end users. Material flow can t>e characterized as linear. II. Equipment Repair: F^led items are sent to the repair 
35 fadlities. repaired using resources (ag.. humans arxi test equipment), and restored to usable condition. Material flow 
can be characterized as reentrant 

Even though a typical manufacturing environment may perform a limited anKXjrrt of repair operations, such as 
machine maintenance or product service, its resources are predominantty dedicated to material procurement finished 
goocfe production and cfistrftxjtion. In this view, tfie cfistinguishing characteristic between the marufacturing and repair 
40 environments is the degree to which the environment focuses on the production of new goods versus the repair of old 
ones. Compared to the maruifacturing supply chain, the equipment repair supply chain has complex reentrant fkiws, 
while the maruifacturing is characterized by the linear material flows from material procurement to final consurrption. 

DSS Database 

45 

Overview 

The DSS Datat>ase 12 is internal to the DSS 10 iirplementatioa The main objective of the DSS Datak>ase 12 is to 
support the executfon of the dedsion support functionality of the DSS 10. It contains the synthesized data drawn from 

50 a variety of external siifipty diain information sources and Supply Chain Information Systems 15. It may also maintain 
a set of data unique to the DSS 10 but not available in any ex^'ng Supply Chain Information Systems 15. An example 
of such unique data is the data derived through the analyst of synttiesized data. The DSS Database 12 can be inter- 
faced to the Supply Chain Information Systems 15to retrieve ttie required data and provide updated data, as needed. 
The Database Management System 1 4 (DBMS) communicates with the Model Engine 20 to provide the input data. 

55 and update the database 1 2 based on the output of the Model Engine 20. In general the DBMS 1 4 does not duplicate 
tfie transactiorvbased functionality tf^ is typicaDy featured in the Supply Chain Information Systems 1 5, unless it is crit- 
ical for dedsion support needs. 
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Data Representation Scheme ^ * • ^ - • f, ♦..m^, . 

Choosing an appropriate data representation is inportant to ensure data consistency, and reconfigurability. 
5 Stmctural Data Representation 

A structural data representation of the data in various data spaces 50. 52 and 54 (see figure 4) is used to model 
the elements of the sipply chain that are relatively static. Specifying ttiese data elements typicaOy specffies the infra- 
structure of the supply chain. At the highest level of abstraction, four principal nodes (see figures 5 and 6) in the supply 
10 chain 58 are identified: 

Demand node 59: The customer demands are characterized at this node. 

Inventory Node 60: Inventories of key components or finished goods are identified to be at these inventory nodes. 
Production Node 61 : Production resources {or finked goods suppfy) are located at production nodes. 
75 Component Supply Node 62: The SL|3ply points of key components are characterized at the component supply 
nodes. These sb-uctural data elements are spatially disttxited along the supply chain 58 (see figure 5). The rela- 
tionship between these nodes is preferably modeled in the form of a network. The network characterization is a col- 
lection of Onks tiiat connect the princpal nodes. A link establishes a logical relatkxishp between two nodes, which 
may have several attrftxjtes such as distance between the two nodes, transportation lead time. etc. 

20 

In greater detaD, the structural data elements and their relationship to the principal nodes are desabed as follows. 
Key components 63 are suppBed l3y component suppDers 64 tied to specific component supply nodes 62. Production 
resources 65 produce the various products 66. The production resources can be aggregated into production resource 
groups 67. and are kx:ated at production nodes 61. Products 66 are the end items ttiat are produced and. based on 

25 tfieir various attributes, can be grouped into various product groips 67. These products are stocked at various stock 
locations identified with inventory nodes 60 and inventory headers 68. Customers 69 can be grouped by various criteria 
into custonoer groups 70 and demand vanois products. Customers 69 are k>cated at the demand nodes 59. Markets 
71 are defined for a cross-section of customer s and products. 

A similar structure can be provided for the repair chain as illustrated in figure 6. 

30 Such a data representation in the form of a network of nodes and tiie ability to group tiie various constituent ele- 
ments, provide the flexibility to specify and reconfigure a variety of supply chains. 

Process Data Representation 

35 In adcfition to tiie structural elements, ttie data associated witii tiie various processes in the supply chain need to 
be represented. These process data elements are relatively dynamic with respect to time and ttie associated processes 
transform data related to the various structural elements. To characterize the process data, we introduce a few addi- 
tional data structures. 

40 Data Space 

A data space is a fundamental domain to characterize basic data elements associated wrtti tiie supply chain man- 
agement demand, supply and inventory data. The data spaces 50. 52 and 54 tie tiie structural data to tiie process data. 
It has ttiree principal dimensions: Product/Component; Tnme; and Node related structural element. As tiie node-related 

45 structural elernent can be a customer, an inventory kx:ation. or a production resource. The 

be at any resolution (in terms of level of aggregation) ak)ng the three dimensions and can be expressed as a quantity 
or value. Thus, each point in ttte data space characterizes the resolution of the product (or corrponent), ti^ time and 
the node-related structural element. For exanrple. when descrft)ing the aggregate production plan data, a product can 
be at tiie resolution of product time at a resolution of week, and the node-related structural element (Production 

50 resource in this case) at a resolution of production resource group. On the other harxi. in describing bottom-up fore- 
casts, a product can be at tf>e resolution of product, time at a resolution of month, and node related structural element 
at the resolution of o^tomer. 

We identify ttiree prinqpal cteta spaces associated with supply chain management: Demand Data Space 50; Inven- 
tory Data Space 52; and Supply Data Space 54. These data spaces are pictorially represented in figire 4 and are 

55 explained next 

Demand Data Space 50: This (teta space 50 has ttiree dimensions: Customer; Product; and Tima Cu^omer can 
be at a resolution of customer or customer group or demand noda Product can t>e at the resolution of product or prod- 
uct group. Time can be at a resolution of day, week, bi-week. nxxith, bi-montii, quarter or year. 

Su93ply Data Space 52: This data space 52 has ttie foltowing ttiree dimensions: Production Resource; Prod- 
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uct/Confponent: and Time Production resource can be at a resolution of production resource, production resource 
group, or production node. Product/Component can be at the resolution of conrponent product or product group. Time 
can be at a resolution of day, week, bi-week. month, t>i-month, quarter or year. 

Inventory Data Space 54: This data space 54 has tf)e following three dimensions associated with rt: Inventory Loca- 
tion; Product/Component; arvJ Time. Inventory location can be at a resolution of stock location or inventory noda Prod- 
uct/Component can be at the resolution of component product or product group. Time can be at a resolution of day, 
weeK bi-week. nfX)nth, bi-month. quarter or year. 

A decision process relates or transforms data either within a data space or t>etween data spaces. For example, 
aggregate production planning transforms data from the supply space to inventory space and vice versa. We will 
employ this data space representation to specify the various decision processes in supply chain management 

The DSS Database 12 corrprises structural information (information related to relatively static information such as 
product groups, market groups, supply chain network, etc.), and process information (dynanvc information related to 
demand, production plan, etc.). Rgure 5. previously discussed, graphically represents the structural data tables for the 
manufacturing supply chain. 

Similarly, the DSS Datat>ase 12 for the equipment repair supply chain (see figure 6) comprises structural informa- 
tion (information related to relatively static information such as equipment repair resources, supply chain network, etc.), 
and process information (dyrramic information related to usage, requirements, repair plan, etc.). Again, tfie structural 
elements are i\ex!bfy collected into different groips to alfow users to analyze data at various resolutions. For example, 
equipment of the same age can be grouped together to analyze the effect of age on repair requirements. Rgure 6 
graphically represents the structural data tables for the equipment repair supply chain. 

The process data in the DSS Database 12 are contained in two closely related table type data structures (see 
below): (I) header file that specifies the resolutions and values on the relevant dimensions of product, custon^, time, 
resource, and item, (ti) corresponding data file which contains the actual data at thie resolutions and values specified in 
the header. The process data are preferably stored in these two tables (Tatile 2, Table 3), rather than one consolidated 
table (Table 1), to avoid redundancy and updating anomalies. A loss-less join of the header and the data tables will 
result in the consolidated tat)le (Table 1). The folfowing example demonstrates this pant 
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Table 1 

A single consolidated table with redundancy (not in normal form) 
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Oriencation 


Cusconer 


6utaiierU 


Product 


ProductIO 


.Time 


Calendar ID 


Date 


HeadftrZD 


Resolution 




Resolution 




Resolution 




Created 




5 






19Pkl4e 


M 




l/lM 






5SSH- 


P ' 


19PSS2C 


H 




i/iM 




<!■■ 


BBSTU 






M 




1/1/96 




c ■ 




P 


554538 


M 




1/1/96 




5 


— mss~ 


P 




M 




1/1/96 




^ ..... 


^5U£ 


P 


6P4S40N 


M 




1/1/96 




■ — ^ ■ 


SBAStS 


P 


CP4B50M 


M 




1/1/96 



Table 2 

Header table that provides the series information 
and the various identifiers 



Orientation 
Header ID 


Time 
Period 


Quantity 


1 


8/1/96 


10 


2 


6/1/96 


20 


2 


7/1/96 


30 


2 


8/1/96 


75 


2 


9/1/96 


50 


3 


6/1/96 


12 


3 


7/1/96 


40 


3 


8/1/96 


57 


4 


9/1/96 


50 


4 


10/1/96 


2 


4 


7/1/96 


3 


5 


1/1/96 


40 


5 


2/1/96 


2 


6 


5/1/96 


74 


7 


3/1/96 


3 


7 


6/1/96 


565 


7 


4/1/96 


500 



45 

Table 3 

Data table that contains references to the header table 
and the time series data 



Data tables 

The data tables in the DSSDatabase12arepreferably specified as foltow^: Name ^ Brief description of 

the data contained in the table; Identifier for the data fields; Type of tfie data field; and Brief description of the data fields 
(tfi^ indudes the choice of values for the data in this field, if appficable). 

The specifications of the data tables for tfie manufacturing and equipment repair supply chains can be found in 
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' Appencfices A and B, respectively. The list of thiB preferred tables in the DSS Database 12 for these chains is as follows: 
Aggregate Production Plan Data; Aggregate Production Plan Head^; Budget Data; Budg^ Head^; Calendar; Com- 
ponent; Component Accommodation Matrix; Component Requirement Data; Component Requirement He^er; Com- 
ponent Suppfi^; Conpon^ Supply Contract; Component Supply Node; CPRD Table; Customer; Customer Grotp; 
Customer Groip; D^inition; Ci^mer Orders; DataField Defffirtion; Demand History Data; Demand History Header; 
Demand Node; Demand Orientation Data; DemarvJ Orientation Header; Domain; Domain Definition; Feature Choices; 
Forecast Data; Forecast Header; Freight Rate; Inventory Data; Inverrtory Header; Inventory Node; Inventory Parame- 
ters; Market Data; Market Header; Material Delivery Schedule Data; Material Delivery Schedule Header; Planning 
BOM; POS Data; POS Header; Product; Product Features; Product Groip; Product Group Definition; Production 
Accommodation Matrix; Production Capacity Data; Production Capacity Header; Production Matrix; Production Node; 
Proc&jction Rec^iremertts Data; Production Requirements Header; Promotion Data; Promotion Header; Resource; 
Resource Group; Resource Group Definition; Sales Requirements Data; Sales Requirements Header; Scenario; Sce- 
nario Data; CompatOsilfty; Sc^iario D^tnition; S^up Matrix; Supply Chain Network; Supply Order Data; SLf)ply Order 
Header; Temporary Product Ust; VMR Contract; VMR Data; and VMR Header 

Core Reports 

The present invention preferably provides core reports that support business decision processes by characterizing 
ftre link b^een the various data elements an6 processes. They synthesize the data and irTformatk>n used in the ded- 
sk>n making processes. Associated with each key business process, we will d^nonstrate the data f bw relationships 
that are used to construct the various forms and reports. Some of the preferred forms and reports relevant to the DSS 
10 are: Sales Plan; Customer-Demand History; Production-Sales-lnventory Plan; Master Productk)n Plan; Production 
Capacity Plan; Replenishment Schedule; Customer-DC Assignment; and Siq^pty-DC Assignment 

Dec^on Support Frames 

Overview 

From a user perspective, a Frame 16 is an integrated decision sif)port environment t>a5ed on an at>straction of the 
supply chain designed to address a set of related decision problems within a decision process. A Frame 1 6 is therefore 
defined based on the vantage point or view point of the users along a supply cfiain. This implies that a frame exists if 
arxi only if tfiere are users with specific needs in the supply chain. 

Rom a system perspective, a Frame 16 is a mechanism tfiat unifies the user dialog and cfisplay, the models and 
analysis routines, arxJ data in a manner ttiat is conststerrt to support the underiying supply chain abstraction of the user. 
A summary of tfie frame concept from txjth a user and a system perspective is shown in Table 4. 
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User Perspective 


System Perspective 


An environment to address 
a collection o£ related 
decision problems. 


It is a subsystem that 
processes user requests in 
the form of Scenarios. 


Always associated with a 
decision maker or a group 
of decision makers. Frame 
exists if and only if 
there are decision makers. 


It consists of a 
consistent set of process 
and data models. 


Has a unique perspective 
of the underlying supply 
chain based on the 
responsibility of the 
decision makers associated 
with the frame. 


It imifies the User 
Interface, Model Engine, 
and DSS Database elements 
that are specific to a 
decision making process . 


Enhances the coordination 
of decision making 
implicit in the definition 
of the frsune. Enforced 
through organizational 
accounteibility and 
responsibilities . 


A convenient client -server 
architecture that encJDles 
the extension of the DSS 
f unct ional i ty . 



Table 4 

Frame Concept: User's and System Perspective 



30 

Rame Architecture 

The high level design of a Decision Support Frame 16 and its interaction with the User (rrterface 18, the Supply 
35 Chain Frame Manager 24, the Model Engine 20, and the Datat>ase 12 is illustrated in figure 7. A Frame 16/72 is the 
abstracticn of the supply chain from a user's point of view, tt essentally contains as its design elenrients a user dialog 
72 and user display 74 and a decision logic 76. The user cBalog 73 and the display 74 contain the form and style of the 
User Interface 18. The decision logic 76 permits the asserT4)ty of models and analysis routines and the assocated data 
to address the set of related decision problems. For example, in the case of the PSI Planning Frame 16|0. the user cfia- 
40 log 72 and display 74 are ct^tomized to the specific needs of the PSI planning process, which further determines the 
design of the User Interface 18 associated with the PSI Planning Frame 160. Users will interact with the PSI Planning 
Rame 160 through the User imerface 18 by fbrnrulattng Scenarios 78. Based upon th^ the decision logic 

76 in the PSI frame may assemble models arxJ routines from the Model Engine 20 along with the associated data. The 
decision logic 76 in a frarrie interacts with the Supply Chain France Mariager 24 to execu^ 
45 Supply Chain Franrte Manager 24 tften provides the perfornriance feedback to the user. 

Decision Processes in the Manufacturing Supply Chain 

The decision processes in the manufacturing supply chain are depicted in figure 8. We frave identified five decision 
50 processes closely associated with the key decision makers and potental users in a supply chain: Overall Supply Chain 
Management 80, Demand Management 81, PSI (Production-Sales-lnventory) Planning 82. Supply Management 83, 
and Vendor Managed Replenishment (VMR) 84. 

Overall Supply Chain Management 

55 

A supply-cf^n-wide view and the necessary Management 80 \s reco^ized by all levels of the nrtanagement as 
beir^ vital to managing the business. However, decision makers at different levels and points akxig the supply chain 
are primarily motivated by tfieir individual roles arvJ respor^lsifities. The broader a decision maker's responsSxIrties. the 
more likely the decision maker is interested in emptoying dectskm support capat>iOties that target the entire sifiply 
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chain. The user requirements discussed below for decision support are posed from a suppfychain-wide perspective/^- 
Given the uncertainty in the medium- to lor)g-term sales forecasts, determine whether or not the enterprise should 
expand, maintain or reduce Hs production capacity arxi/or stocks tor the cnttcal components. When changes in busi- 
ness condrtior^ impact one part of the supply chain, assess the potential impact on the other parts of the supply chain. 
Given different future business scenarios, determine their financial consequences aaoss the sv^fy chain. For the 
enterprise's supply chain which includes major retailers, determine the appropriate division of respons3)ilrties for all 
partners in the supply chain. Develop and implenrtent perfom^arYce incentives that will entiance and encourage supply- 
chain-wide thinking and decision making in the enterprise. 

Demand Management 

Demand Management 81 ts the process by wtiich the customers' requirements are characterized with the specifi- 
cation of prevailing unc^tainty. The process involves the development and nrtaintenance of mecfium-term customer 
(bottom-up) forecasts. These forecasts are initially developed in periocfic joint meetir^ or communications t>etween the 
decision makers of the enterprise and the customers. Sut)sequentiy. these forecasts are input into the enterprise's sup- 
ply nanagement system to obtain product allocation approval (place-keeping order). As the actual purchase orders 
arrive, the enterprise attempts to futfiil the requirements to their customers* satisfaction. We have identSied the user 
requirements discuss below for decision support for ttiis process. Syrrthesize information from different sources in order 
to manage the demand requirem^its effectively, e.g., accessing point-of-sales (POS) data axudi comparing these with 
shipment history arxj customer forecasts. For key customers, devek)p customer-specific sales forecasts based on his- 
torical shipment and sefl-through data. Link POS data, where available, to the historical promotion infonnation to ana- 
lyze the real impact of promotion activities on demand, as opposed to relying on the estimates provides by the retailers. 

PSI Planning 

PSI Planning 82 is a process to detenmine a set of feasSile sales, production and inventory requirentents for 
medium to tong-term capacrly and resource planning for tiie logistics operations. At the beginning of each fiscal year, 
an initial PSI plan can be developed based on the long-term top-down sales forecast and budget plans. The planning 
process then becomes a continuous effort to update the existing PSI plan to accommodate the changes in the require- 
ments t>efore and after a series of monthly PSI planning meetings whose participants include dectston makers repre- 
senting all key functional areas at the enterprise. The meetings inte^ate ttie inputs from various sources, resolve 
possible conflicts, and balarx;e the concerns of different functk>ns in order to reconcile, develop and approve a new set 
of feasible sales, production and inventory requirements. The process represents a focal point for the entire logistics 
planning process, and interacts and coordinates with all major dectsk>n making processes. We have identified ttie user 
requirements discussed bekyw for decision support for this process. Generate market trend forecasts by product cate- 
gories for the enterprise as well as the entire industry. Such forecasts will be based on available sh^xnent hstory, indus- 
try survey data and influential ecorK>mic indicators. Generate forecasts for new products and managing product 
transitions. Facilitate devek)pment of medum-term top-down and bottom-up sales forecasts for the enterprise. Fadlitate 
development of production plans and the associated requirements plans for critical oonponents. Evaluate the effects 
and understand tiie implications of spedfk: changes in the sales or production plans. Conflict resolution mechanisms 
are needed to adapt and maintain these plans. Uentify those products that would be affected by tiie shortage of certain 
critical components; one poss&le approach is to use an irrploskxi tool on the biU of materials. Provide a formal mech- 
anism to determine and reacQust appropriate inventory levels for various products. 

Supply Management 

Supply Management 83 is a process to determine the production (supply) plan to meet the production (supply) 
requirements generated by the PSI Planning process. The process involves component procurement and factory pro- 
duction planning based on the PSI plans and their changes. At the beginning of the process, the production line capac- 
ities are aeated based on long-term product plans, i.a, planned new product release. The process continuously 
updates tiie production (supply) plan based on changes in the production (supply requirements generated in the PSI 
process. We have identified ttie user requirements discussed befow for dectston support for ttiis process. Determine ttie 
feasibflity and the economic viability of changes in ttie production (supply) plan, when changes occur in ttie PSI plans. 
This requr&nent is motivated by trade-offs t>etween the PSI process and the production (supply) planning process. 
Evaluate possble options to acoomnmiatechariges in the production requirenients. after the Gne structure and capac- 
ity are determined. Such an analysis is a requirement of the factory planner. Devefop an aggre^e level representation 
of the production line capacities so ^ to help the planners in developing ag^-egate production plans or checking pro- 
duction capacity. Develop a rough-cut analysis capatMltty to assist the planners in translating the production require- 
ments into critical component requirements* i.a, conponents featured in the planning bill of materials. 
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~ - Vendor Managed Replenfehment (VMR)--- — ^r^f' . - : • - — -w^- v 

VMR 84 is a process in which the supplier takes on the responsd>irity of managing the inventory at the customer 
site lor the products it supplies. TTus process operates on pointKrf-salesdeniand as opposed to demand forecasts pro- 

5 vided by the customers. VM R involves formulating the contractual agreements between the enterprise and the retailers 
as well as determining the operating parameters such as shipment quantities and replenishment frequencies. We have 
identified the user requirements discussed t>elow for decision support for this process. Develop a strategic analysis tool 
to determine mutuaUy benefictal VMR contracts based on financial and logstics factors. Develop the replenishment 
plan based on factors such as sell-through and inventory information provided by the retailer, pronrmtion activities, prod- 

10 uct availability and trartsportation cost trade-offs. 

Decision Processes in the Equ9>merTt Repair Supply Chain 
Overview of the equipment repair supply chain 

15 

The ec^ipment repair supply chain 90, as depicted in figure 9; includes the operating location 92, i.e., the pdnt-of- 
use. the repair shop 94. and the corrponent suppliers 96. In an equipment repair supply chain, the demand (or the 
"requirements") are generated by equipment failures. When equipment fails, the failed module is replaced from the 
stock at the operating location 92, arxJ tfie faOed module is eventually sent to the repair shop 94 for repair. A rrxxJule is 
20 made of repair items which in turn are made up of components. At the repair shop 94. the repair is carried out by the 
repair resources (people and machinery). Dmng the repair process at the repair shop 94, certain repair items and com- 
ponents are replaced. Based on the repair needs, repair items and components will be ordered from the sources of sup- 
ply by the repair shops. 

Equ^pntent Operating Location 92: At the equipment operating location 92. personnel may replace only certain 
25 repair items of the nxxJule. instead of the whole module These replacement repair iXervs may come from the stock or 
from other failed nxxiules. The process erKOurages consolidation of failed nxxlules at the operating focation. In the 
consolidation process, the broken repair item of a broken nxxtule is replaced by a good repair item from another broken 
module. Th^ process may be nrxitivated by the structure of the repair cost function and the need for quick repair. In 
some cases, due to the f ixed costs of serxiing individual modules to the repair shop, modules are t>atched to a certain 
30 level, before th^ are sent to the repair shop for a complex overtiaul. . 

Repair Shop 94: The repair shop 94 is responsfole for all the major repairs. The type of repair to perform is driven 
by the level of good modules at the repair location. When good modules are sent from the repair shop to the operating 
location, the stock level may drop befow the target level, thus triggering a repair request to bring the stock level up to 
the target level. This target level is determined with the objective of maximizing the equ^ment availat)itity and minimiz- 
es ing the repair costs. Component and capacity requirements corresponding to a repair request should be feasible with 
respect to component availability and resource capacity levels at the repair shop. 

Parallel with the manufacturing supply chain: 

40 We recognize the operational differences b^een manufacturing and equipment repair supply chains. However, 
the equipn>ent repair simply chain has dear parallelism with the manufocturing supply chain where the repair items cor- 
respond to products and compor>ents correspond to materals. Equipnnent operating focations are similar to retailers 
and equipmerrt is Bke customers. The repair shop rs anafogous to a production facOity. As nrvxlules are made up of 
repair iten^ modules correspond to product groups. The repair requrements management process is anafogous to 

45 demand management, and repair supply management to supply management. Similar to the PSI process, there exists 
a reconcniation process in the equipment repair supply chain to ensure balance between requirements and supply. 

Application to a national defense application 

50 For a national defense appfication. the following nomenclature is used. The equipment located at various operating 
locations are the aircraft operating at ttie various t>ases. The modules correspond to the Line Replaceable Units, or 
LRUs and the repair items correspond to Shop Replaceable Units (SRUs). The failure of an LRU, caused t)y the failure 
of its SRU, rerxters the aircraft unavailabia The function of ttte base is to provide irrvnediate support to the aircraft 
located at that base, with the objective of rnaxtnrvzing avails For that purpose, t>ases stock good units of 

55 replaceaUeitenris, caOed serviceables, so as to be able to replace a failed LRU of an aircraft irmie 

ally, is not involved in major repairs. Instead, it implements a consolidation policy (replacing the defective SRU of a 
newly failed LRU with a good SRU of an already defective LF%J), which gives the fc>ase the abiTity to manage the repair 
requirements of the depot Managing the repair requirements refers to deciding wt^ and which defective items the 
base will send to the depot for repair with the objectiveof niaxirnizing ttie availability of aircraft located al^^ 
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minirnizing total <X)st of repair (which indud^ .-^-- ^^ - K^v-y.^ ncu-i-. - - . — 

A depot is responsble for aJI the major repairs. The type of repair to perform is driven by the level of good repairable 
items at the depot When good repairable items are sent from the depot to the base, the stock level may drop t>elow the 
target level, thus triggering a repair request to bring the stock level up to the target level. This target level, also called 
the Consolidated Servk^eable Inventory (CSI) level, is determined by the depot with the objective of maximizing its serv- 
ice level and nvnimizing its repair costs. Component and capacity requirements corresponding to a repair request 
should be feasble with respect to conrponent availability arxi resource capacity levels at the depot 

Table 5 below presents the analogy and nomenclature between the equipnient repair si4)ply chain, and the manu- 
facturing supply chain with examples from defense and commercial environments. 



Equipment 
Repair Supply 
Chain 


Example 
Defense 
Equipment 
Repair Supply 
Chain 


Example 
Commercial 
Ecjuipment 
Repair Supply 
Chain 


Parallel with 
Manufacturing 
Supply Chain 


Equipment 


Aircraft 


NRI Machine 


Customers 


Mcxlule 


LRU 


Cabinet 


Product Group 


Repair Item 


LRU / SRU 


Circuit 
Boards 


Product 


Component 


Bit and piece 
part 


IC 


Component 



Table 5 

Analogy and nomenclature between equipment 
repair auid manufacturing supply chains 



Decision Processes in the Equipment Repair SufDply Chain 

The supply chain comprises (see figure 9) the following three decision processes: Requirements Management 
Process 98; Requirements-Stpply Recondliation Planning Process 100; and Supply Management Process 102. 

Requirements I^Aanag^nent Process 

The Requirements Management Process 98 concentrates on the activitjes associated with requirements estima- 
tion. The objective of this process is to estimate future repair requirements generated tsy equipment ^lures. Equi(»nent 
has several repairable parts and equipment failures are caused tyy failures of the repatratsle parts. Hence estimating 
future requirements refers to the process of estimating failures of the equipment and of the repairable parts tfiat caused 
the failures. This is done to estimate repair time requirements (determined in Requirements-Supply Reconciliation 
Planning Process) and equ^sm^ availabflity at equipment locations, both of which depend on the part tfiat has failed. 

Requirements can be analyzed in two levels: Lower level requirements, called the Raw Requirements, correspond 
to all repair requirements of the equipment and upper level requiremerrts. called the Consolidated Requirements, cor- 
respond to requirements requested from the repair shop, since equ^pntent locations nrtay prefer accumulating their 
repair requirements and sending them to the repair shop accorcfing to certain rules instead of sencfing them as they^ 
occur, a may prefer carrying out minor repairs within the locatk>n, with the aim of reducing the fixed and variable costs 
of repair. In the manufacturing analogy, raw requirements would oonrespond to Point of Sales (POS) data and consoli- 
dated requirements to retailer order data from the production facility. 

Two different estimation approaches that have been used in this process to estimate consolidated requirements 
are: Bottonrhup Estimation Approach; and Top-dmn Estimation Approach. 

The bottom-Mp estimation approach estimates the raw requirements first and then generates the consofidated 
requirements from raw requirement estimates. In order to estimate raw requirements, relationships are determined 
between failure rates and activity schedules of the equipment For eoomple, the tme to faflure of an equipmerrt can t>e 
a function of tfte number of hours it has operated arKl its mairitertance scf)edii& Orx^ 

rates arxi activities are established regression or time series nxxJels, future failure rates can be estimated b^ed on 
the planned activity schedules of the equipment Gdven the estimated raw requirentents, the next step is to go to the 
upper level and estimate consolidated requirements, that is requirements as seen by the repair shop (assunrvng that 
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repair shop does not have access to raw requirements date - 
operating location wiD send its repair requests to the repair shop. This Is analogous to the inventory replenishment pol- 
icy of a retailer in a manufacturing systent tn dectcfing on the type and parameters of the inventory replen^hm^ policy, 
the facOity will use several conflicting performance measures such as minimizing total repair cost and maximizing avaD- 
ai>Oity of the equipment Thus, given the inventory repl&ibhment poBcy of the facflrty arxi estimates of its raw require- 
ments, its consolidated requirements can be estimated. 

The top<iown estimation approach makes use of histork^al data to estimate consolidated requirements. Statistical 
forecasting techniques can t>e used to support this process. 

The two estimates obtained by bottom-up and top^iown approaches are compared, analyzed and reconciled to 
generate final estimates for consolidated repair requirements. The output of this process Is the estimated consolidated 
rec^irements for an equipment operating location. 

Requirements-Stpply Reconciliation Planning Process 

The second process Is the Requirements-Supply Reoondfiation Planning process 100 that aims at developing an 
integrated repair plan for the repair shop through a recondliation process. Rrst the type and paranrteters of the repair 
poBcy of the repair shop are to be determined. Aggregate repair requrements are generated t>ased on the repair policy 
of the repair shop and estimated consolidated requirennenis lor all facOrties. The next step is to generate an aggregate 
repair plan based on repair time estimates for each repairable part and the aggregate repair requirements. FeasS)ility 
of the aggregate repair plan Is checked with respect to resource constraints which are repair resource capacities arvi 
key component availatMlity. If the aggregate repair plan Is not feasible with respect to resource constraints, then causes 
for infeasO^ility are identified arxl the infeastbiFrty is removed tiy either changing the level of the resource constraints or 
moving aggregate requirements forward or backward in tima This procedure ^ repeated until an aggregate repair plan 
that isfeas3)le with respect to resource constraints Is attained. The supply management 102 (see figure 9) Is a process 
to d^emnine the repair plan considering repair people, test equipment and key components. It starts by the translation 
of the aggregate repair plan into a detailed plan conceming repair resources (repair persons and test equipment), and 
component requirements. Based on these requirements and the capacity constraints for the repair resources, repair 
personnel and key components, a detailed repair plan is developed using an optimized based modeling approach. The 
detailed repair plan is used to generate the key component delivery schedule to t>e transmitted to the conponent sup- 
pliers. In addition, the supply managenDent process 102 is also concerned with the devetopment of appropriate procure- 
ment policies tor key components in terms of Identifying the policies, and deriving the corresponding policy parameters. 

Basic Frames 

The basic Frarr^ 1 6 of the present invention collectively provide coverage for tfie overall supply chain. The specific 
instances of these Frames 16 in a particular DSS 10 implementation depend largely on the constituent supply chain, 
the undertying txisiness processes, arxi ttie organizational structura Table 6 befow lists the Decision Support Frames 
16 in the context of maruifacturing arxi equipnDent repair supply chains. 
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Manufacturing Supply Chain 


Chain 


Demand Manaaement 


n,cqu»i.xeiucuus nanagemenc 


PSI Planning 


Requxrement s - Supply 
Reconciliation 


Supply Management 


Supply Management 


Vendor Managed 
Replenishment 




Finished Goods Distribution 
Network Design 





Table 6 

Decision Support Frames in the Context 
of Manufacturing and Equipment Repair Supply Chains 



25 Specrfication of the Basic Frames 

To specrfy each basic Frame 16. we use influence diagrams to map the rrxxlules in the Model Engine 20 arxi the 
Data Spaces to the frame. We use process flow diagrams to outline the high let^el design of the logical relationship 
anf)ong the key data tables, the modides and the basic Frames 16. We also dscuss how to 5Lif)port key functional 
30 requirements in each frame. To complete the specification of the basic Frames 16. we use data flow diagrams to map 
the data tables to the core reports in each frama The legend for the process and the data flow diagrams which will be 
discussed herein after is shown in figure 10. 

Demand (Requirements) Management Franrw 

35 

The Demand Management Frame 130 supports the demarvi managenrtent decision process described here. 

Manufacturing Supply Chain 

40 Module and Data Space Association 

Rgure 1 1 shows the participating nrvxiules and the associated data spaces for this franrta 
The Demand Management Frame 130 requires the participation of two modules: the Sales Forecasting and Plan- 
ning (SFP) Module 132 and the Market Data Analysis (MDA) module 134. The SFP Module 132 in the Demand Man- 
45 agement Frame 1 30 essentially operates in the D data space. i.e.. it transforms data within the conceptual demand data 
domain. The MDA Module 134 in the Demand Man^enrtent Frame 130 operates in the I and the D data spaces and 
. relates the I data space to the D data space. i.e.. it m^ transform data within the individual D data space as well as 
transform data from the I data space to the D data spaca The data space representation of the Denri^ 
Rame 1 30 is the union of the data space representations of each participating module, and the interactions anK)ng par- 
50 tidpating rrxxlules. 

The high level representation of figure 11 can be complemented by the process flow diagram for this frame, 
described next, that will detail the connections t>6tween the constituent rrvxlules and the associated data tables. 

Process Flow 

55 

The process fkMr dagram for the Demand Management Frame 130 is shown in figure 12. The modules, data 
tables, and the principal activities within the scope of this franie are dearly rrtarked by the grooved tx»der. 
Only the data tat)les that are updated by the frame are considered to be within the scope of the frame 130. Other 
franrtes. activities and data tables that are related are also shown for completeness. The Order Fuffniment 149. that is 
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— '^out-of-scope of the Demand Management Frame 130 but related to it, ^ shown separately in figure 13 for purposes of 
darity. This representation of interaction between Frames 16 is consistent with the interaction t>etween dectston proc- 
esses shown in figure 8. 

The D^nand Management Frame 130 supports the functional requirements described below. Demand Character- 
5 ization - Demand data from various sources such as Demand History Data 136. POS Data 138. Market Data 140. and 
Promotion Data 142 as well as top^iown and bottom-up Forecast Data 146 obtained by buyers and account managers 
wiD t>e consolidated arxJ synthesized by the MDA Module 134 and the SFP Module 132. Bottom-up Demand Forecast- 
ing - Demarxj Review 144 cor^idates demarxi information received directly from the customer along with the input 
from the MDA Module 134 and then develops Demand Orientation Data 148. The SFP Module 132 will then use 
10 Demand Orientation Data 148 as well as other inputs, ag. Promotion 1 42 and POS 1 38 Data, to develop the customer- 
centric bottom-up forecasts in Forecast Data 146. Top-down Forecasting - The SFP Module 132 will use market and 
industry-wide trend analysis performed by the MDA Module 134 along with the enterprise's shipment fiistory to gener- 
ate the product-centric topdcwn forecasts in Forecast Data 146. Sales Promotion Analysis - The MDA Module 134 
reviews tfie demand history from POS Data 138 and Demand h^cry Data 136 alortg with the customer promotion 
15 information from Promotion Data 142 to analyze the impact of promotions on sales. The results of such an analysts are 
then used to help adjust sales forecasts to account for promotions. Forecast Performance Evaluation - Using Demand 
Orientation Data 146. Demand Kistory Data 136 and Promotion Data 142, the SFP 132 and MDA Module 134 can eval- 
uate the quafity of enterprise's forecasts and the custonier projections. 

20 Data Row 

The data fksw cfiagram for the Demand Management Frame 130 is shown in figure 14. The Demand Management 
Rame 1 30 generates two of the cae reports listed earfier. namely, the Sales Plan 1 52 and the Customer-Demand H^- 
tory 1 54. For each core report, the associated data tables are shown. The dashed line indicates the influence of an out- 

25 of-sccpe (with respect to the Demand Management Rame 1 30) data table in the development of the report. For exam- 
ple, the Customer Orders data table 150 is outK>f-scope of tiie Demand Management Frame 130 but influences the 
Customer-Demand History report 152. 

Demand Management is the process in which the user determines future requirements based on past requirement 
history and general information related to the supply chain. In the context of the nianufacturing environment Denriand 

30 Management supports the analysis of past demand and of mari^ trends as well as the development of future forecasts. 
For the repair environment the term Requirement Management is used in place of Demand Management Requirement 
Management is the process where future requirements are estimated based on an analysis of each equipmenf s activity 
and on the projection of past requirement history. 

In the manufacturing context. Demand Management regroups the set of processes by which the user analyzes 

35 Market Data 140 and past demand history for the purpose of estimating future demand requirements. The outputs of 
Demand Management include the analysis of past history, future forecasts, the analysis of special activities such as 
sales promotions, and the analysis of forecast errors. Two critical outputs of Demand Management are two different 
medium term faecasts corresponding to two dfferent views on the dynamics of the processes that generate future 
requirements: the customer centric forecast - generated a! the product level for each customer it incorporates the esti- 

40 mations of future demand provided by each custonner (Bottom-tp Forecasl); and the product centrk: forecast - gener- 
ated at the product level, it incorporates the impact of market and industry-wkle trends on future demand for each 
product group (Top-down Faecast). These two types of forecast are generated using: FKstorical projection of past 
demand: Future orders information; Analysis of tfte dynamics and characteristics of the overall mariiet and main com- 
petitors; and Analysis of the inpact of future special commercial activities such as sales pronwftions. These analyses 

45 and projections are grouped in five furx:tk>nal requirements that are detailed in the rest of tti^ section: Demarxi Char- 
acterization. BottonrKip Demand Forecastir^. Top^kywn Demand l=brecasting. Sales Promotion Analysis, and l=6recast 
Performance Evaluation. . , , ...... 

Other frames such as production, sales and inventory (PSO or venda managed replenishment (VMR) may directly 
or indirectly use the output of DemarxJ Management 

50 

Demand Characterization 

The objective of Demand Characterization is to provide the ijs& with an environment where (s)he can access, ana- 
lyze and synthesize demand from different sources. These data include: Sales History data (that include POS and 
55 sh^ment data). Inventory data (relative to the inventory position of its product at the customer's stocking points), and 
Market Data 140. Market Data 140 corresporvj to varkxis quantitative infbrnta^ 
such as Nielsen, that relates to the sales for the type of product consktered in the entire maricet. 
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Acquire, Display. Ecfit Data nr-.-x.-v m t--.. . _ . ^ — . ■ . > - 

Data Acquisition conssts of selecting a Data Doniain (specific pairs of customer and product), and choosing the 
type of data tobecOsplayed (POS, demand history, inventory. Mailoet Data 140). Data can be edited and modified and 
saved along with results of analysis in a scenaria 

Analyze & Synthesize Data 

Sales History and Customer Inventory Data 

This involves the operations discussed below. 

Compute, display (tables and graphs), characterize and analyze sales history per product/jproduct group or cus- 
tomer/customer gro(jp (see the MDA Module specification discussion for details of models and formulas): Volatility of 
demand, Lunrpiness of demand. Trends in danand history. Demand pattern changes, and Se^onality. 

Compute, display (tables and graphs) and analyze sales history s tatis tics for different levels of aggregation: This 
year vs. last year. Actual sales vs. budget, aixl Ygar to date vs. balance of Year. 

Compute. (£spl^ (tables and graphs), arxi analyze trend in Demarxi Product Mix by product group. 

Pareto analysis of sales (or inventory) to identify ABC classification for products (see MDA Module specification for 
detaite of fomrulas). 

Compute and analyze corrdation between the demarxi for cfifferent product ^oi4>s. 

Compute, cfisplay (tables and graphs), and analyze new products and model change-over prof Oes. 

Compute, cfisplay (tables and graphs), and analyze inventory profile per customer. 

Compute, cfisplay (tattles and graphs), and analyze trade inventory by comparing POS and shipment data. 

Market Data 

This operation involves the operations discussed below. 

Disptey (tables and graphs) Market Data 140 (volume, value, market share) by product group, region, or customer 
group (Nielsen, EIA. etc.). 

Compute, display (tables and graphs) and analyze Marioet Data 140 statistics for different levels of aggregation: 
This year vs. last year. Trend, Actual statistics vs. budget assumption, and Seasonality. 
Pareto analysis of competitors (value and volume). 
Create price information: list of competitor products per price ranga 

Bottom-Up Demand Forecasting 

The objective of the Bottom-ip forecasting is to devekp a custonrter specific sales forecast based on hist^^ 
ment to the customer, POS information at the customer focation. and tt)e customer's own forecast regarding its future 
orders. 

Acquire. Display. EdBtdata. 

Data Acc^isition consists of selecting a data Domain (spedftc pairs of customer and product), and choosing the 
type of data to be displayed: shipment or POS (when available). 

Forecasts generated in the Bottom-up forecasting frame can be saved back to the DSS Database 12 or alterna- 
tively saved as scenario. 

Bottom-up (BU) Forecast generation 

This operation involves the operations discussed t>efow. 

Input and maintain customer orders: Forward orders, and Orientation orders. 

Choose model for statistical forecast 

Generate and display (tables and graphs) statisti cal forecast at different level of aggregation (POS or Shipment 
data): Customer group. Individual custonriers for an products, aixl Inctividual customers for each pro^^ 
Support integration in BU forecast of expert knowlec^e for optimstic4>essimistic forecast 
Fbrnrnilate disaggre^on togic of BU Forecast aft custorner level onto pr 
Incorporate impact of future promotions for customer specific promotions. 
Compute, cfisplay and ecfit seasonatity factors. 
Retnew actual seasonafity against planned and "company" seasonality. 
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Dtsag^'egate yearly forecasts onto each period using seasonality factors at different levete of aggregation (POS or 
Shipment data): Customer group, Incfividual custonr^ for aD products, and Individual o^tomers for each product. 

Compute and display (tables and ^aphs) sales and forecast statistics: Moving average. Year to dateA>alance of 
year. This year vs. last year, and Actual/forecast vs. Budget 

Support comparison of POS and Shipment data for analyst of change in trade inverrtory prof ila 

Invoke forecast accuracy estimation routine. 

Top-Dcwn Forecasting 

The objective of the Top-down forecasting is to devefop a product centric sales foreca^ t>ased on historical demand 
data and irxiustry analysis tf^t accounts for market-wide trerxis. 

Acquire, Display, Ecfit data. 

The data Acquisition consists of selecting a data Domain (specific pairs of customer and product), and choosing 
the type of data to be delayed: shipment or POS (when availat)le). 

Forecasts generated in the Top^lcwn forecasting fran^ can be saved back to the DSS Datat>ase 1 2 or alternatively 
saved as a scenaria 

Top-down (TD) Forecast generation 

This operation involves the operations discussed belcw. 
Choose model for stattstical forecast 

Generate and deplay (tables and graphs) statistical forecast at different level of aggregation (POS and Shipment 
data): market level, product group level, and product fine lev^. 

Incorporate industry trend analysis developed in Demand Characterization in TD forecast. 
Formulate disaggregation logic of TD Forecast at product level onto customers. 
Incorporate impact of future product specif tc pronxitions. 

Compute and display (tables and graphs) sales and forecast statistics: Moving average, Year to date/balance of 
year. This year vs. last year, arxJ Actual/forecast vs. txidget 
Compute, display and edit seasonality factors. 
Review actual seasonality against planned and "company" seasonality. 

Disaggregate yearly forecasts onto each period using seasonality factors at different levels of aggregation (POS or 
Shipment data): market level, product group level, and product fine level. 

Support forecastir^ of model charige ever, and introduction of new products. 
Invoke forecast accuracy estimation routine. 

Sales Promotion Analysis 

The objective of Sales Pronxstion Analysis is to analyze the impact of promotional activities. It entails maintaining 
the promotion calendar, estimating the impact of future promotions and assessing the ^fect on sales of past pronDo- 
tional activrties. The pronrxition calendar is a table in wftich the various characteristics of past and future promotions are 
recorded. The knowledge and insights gained in sales pronmtion analysis are used in acgusting bottom-up and top- 
down sales forecasts. 

The functfonal features associated with Sales Pronx^tfon Analysis are given befow. 

Maintain Promotion Calendar and add new promotions: Time period of promotfon. 

Type of promotion (defined by who initiates the promotfon: firm, retafler, competitor), and Class of promotion 
(defined by the nature of the promotfonal activity). 

Intensity of pronation: Search and sort promotion calendar, arxi Armlyze Past Promotions. 
Display sales data afong with information of prorrv^tions urvJer consideration. 
Estat)lish profile for the impact of tfie sales promotions. 
Analyze promotion(s) effect through regression or time series models. 

Partition sales: D^ay actual sales attrfoutable to normal sales, seasonal effect and pronriotion effect. 
Plan Future Promotions. 

Add pronfK>tfon in promotion calendar - specify type, dass, intensity and time period. 
Estimate inrpact of future promotion t>ased on the irrpact of simBar past pronriot^ 
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- Forecast PerfonranceEvatiation - • - - • <-*-'- v^--<x^-* . - 

The objective of Forecast Performance Evaluation is to assess the accuracy of past sales forecasts. Forecast accu- 
racy is an inportant measure for several purposes: 
5 It helps the user to refine the forecasting process by providing feedback on the ability of different models arxi 
approaches to forecast future demand; 

ft provides a measure of demarxl variabnity that is used to assess necessary safety stock; arxJ 
ft guides attention to those products arxi customers for which demand is difficult to forecast and that require special 
attention. 

10 Two types of forecast perfonmarx^e evaluations are considered: forecast accuracy of one particular version of the 
forecast and average accuracy of n periods ahead forecast. 

TTie first forec^ performance type provides point estimations of forecast accuracy, while the second one is an 
average estin^tion of the accuracy as a function of the number of period in advance a forecast is produced. 
The functional features associated with Forecast Performance Evaluation are given below. 
IS Select data domain. 

Compute and cfisplay Forecast errors for: Bottom xsp forecast Top down forecast, and Sales plan (invoked from 
PSI). 

Kteintain Accuracy Matrix for each type of forecast (table of the forecast accuracy n periods ahead). 
Generate exception report based on level of forecast error for different level of aggregation. 

20 

Equipment Repair Supply Chain 

In the context of the Equipment Repair Sipply Chain the term "Requirements Management** is used in place of 
"Demand Man^en^nT to indicate that equipment generates 'repair requirements' when it breaks down. 
25 Requirements Management is the process of estimating the future requirements of reparable items at the equip- 
ment location. This process can be divided into two main sut>-processes: 

Evaluation of the raw requirements for each equipmerrt; and 

Estimatfon of the consolidated requirements at the le^^el of each location (several pieces of equipment can be 
30 located at the same location). 

These two approaches can be used to estimate future consolidated requirements. 

Bottonrvup method: This approach uses a combination of two models: (1) the first model estimates the raw require- 
ments of an equipment by modeling its failure rate as a function of the equipmenfs activity (or usage) arxi (2) the sec- 
35 ond model estimates the consolidated requiren^ based on the raw requirements arxi the consolidation policy. 

Top down method: This approach is t>ased on the projection of historical data for the consolidated demand. To sup- 
port the two different approaches the functfonal requirements detailed befow have been d^ed. 

Activity tracking for raw requirements estimatfon 

40 

This involves the operations discussed t>ekiw. 
Select arxi Display Activity Data. 

Maintain Future Activity Data: Planned Equipment upgrade/maintenance schedules; and Planned Equipment 
usage schedules. 

45 

Analyze Past Activities 

Review activities: Display historical raw requiremerrts data afong with activity cteta. 
Assess impact of past activities using regressfon or time series models. 
50 Per type of equipn^ent 
Per type of activity. 

Relate futire raw requirements to planned activities. 

Use models of past activities to project the effect of future activities. 

55 Consolidated requirements estimation based on raw requirements (bottom-tp) 

Th^ operation irM>tves the operations discussed befow. 
Select and Display Consolidated Requirement data. 

Formulate, arxi refine consolidatfon policy (see SFP Module for explanation regarding consdicMon policies). 
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• Evaluate cfifferentconsolictation polidesb^ . -ct^*-- 

Estimate future consoGdated requirements based on chosen poDcy. 

Consolidated requirements estimation based on hetorical data (topdown) 

5 

This Involves the operations discussed below. 
Select and Display Consolidated Requirement data. 

Choose nxxlel for statistical forecast of future usage per repair item/repair Item group. 

Kalman RHer based algorithm for requirements estimation (considered appropriate for forecasting equipment fail- 
to ures). 

Other statistical forecasting techniques. 

Generate and display (tables and graphs) statistical forecast at different level of aggregation: Repair item group, 
IncGvidual Repair item for aQ equipm^ and Individual Repair item for each equipment 

Conrpute and display statistics (tables and graphs) for actual arvl estimated consolidated requirements: Moving 
15 average. Year to date/t>alance of year. Thisyearvs. last year, and Actual/forecast vs. Budget. 

Develop disaggregation logic of consolidated requirements estimation Forecast at repair Item groip onto individual 
Repair item. Lteers can override algorithm based estimates. Requirements reconciliation and requirements plan gener- 
ation 

This operation involves the operations discussed below. 
20 Conrpare and analyze tofxiown and bottom-up requirements numerically and visually 
Reconcile the top-down and bottom-up requiren^ents to generate the requirements plan. 
Use weighted average models. 
Incorporate user's input and ovenida 

25 Requirements estimation performance evaluation 

Store topKtown, txittom-up and reconciled requirements estimates. 

Corrpute and display Estimation errors for: Bottom up requirement estimation. Top down requirement estimation, 
and RecorKiled requirement estimation. 
30 Maintain Accuracy Matrix for each type of requirement estinoation (tat)le of the accuracy n periods ahead). 
Generate exception report based on level of estimation accuracy for cfifferent level of aggregation. 

Production-Sales-lnverrtory Planning (Requirements-Supply Reconciliation) Frame 

35 The PSI Planning Frame 1 60 supports the PSI planning decision process desait>ed here. 

Module and Data Space Association 

Figure 15 shews ttw participating modules and the associated data spaces for this franca 
40 The PSI Planning Frame 160 requires the participation of three modules: the Sales Forecasting and Planning 
(SFP) Module 132. the Aggregate Production Planning (APP) Module 162, and the Rnished Goods Inventory Manage- 
ment (FGIM) Module 164. The PSI Planning Frame 160 as a whole involves S, 1, and D data spaces with iterative data 
transformations among each pair. 

45 Process Row 

The process flew diagram for the PSI Plarintng Firaine 160 is shown 
ports the following functional requirements identifed for the PSI planning decision process: 

50 Forecast Reconciliation 

The Demand Management Frame 130 sipplies the Forecast Data 146 (bottom-ip and top^fown forecasts). The 
PSI Reconciliation Activity 170 in concert with the SFP Module 132 revises the top-down forecasts and reconciles the 
bottom-up and topKtown forecasts. This is an iterative process which is shown as the "S" loop (in ttie top right quadrant 
55 ) in the process flow cfiagram. If any changes to the bottcm-up forecasts are warranted, the PSI Planning Rame 160 
interacts with ttie Demand Management Frame 1 30 to make the necessary changes. 
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• Inventory Planning • - - -wj:^. : 

The PSI Recondliation activity 1 70 in concert with the FGIM Module 164 detemtines the inventory requirements in 
an iterative fashion. This is shown as the loop (in the top left quadrant) in the process flow diagram. The inventory 
requirements are written to Inventory Data 182. The FGIM Modide 164 as part of the PSI Planning Frame 160 also for- 
mulates the finished goods inventory poGdes; the policy paranreters are written to Inventory Parameters 1 72. 

Supply Requirenr^ent Planning 

The PSI Recondliation Activity 170 in concert with the APP Module 160 determines the production requirements 
that are consistent with the sales plan and the inventory requiremerrts in an iterative fashion. This is shown as the "P" 
loop (in the txttom right quadrant) in the process flow diagram. The production requirements are written to Production 
Requiremaits Data 1 74. The APP Module 1 60 as part of the PSI PlannirYg Frame 1 60 also checks aggregate produc- 
tion capacity and key component availabiGty using Production Capacity Data 180 and Inventory Data 182 (component 
avaflability). 

Production-Sales-Inventory-Plan Coordination 

The PSI Recondfiation Activity 170 interacts with the APP Module 160. the SFP Module 132. and the FGIM Module 
164 to coordinate the integrated production-sales-inventory planning. This involves the evaluation of various plan 
options, checking the consistency of the constituent p^ns and resolving conflicts, if needed. 

Data Row 

The data flow cfiagram for the PSI Planning Rame 160 is shown in figure 17. The PSI Planning Frame 160 gener- 
ates the Production-Sales-lnventory Plan report 190 listed earlier. 

The Production-Sales-lnventory (PSI) Rarwiing is a process to recondle demand and supply requirements in a 
supply chain. In the manufocturing environment, the PSI Planning Frame 160 helps to recorK:ile production, sales and 
inventory requirement discreparK:ies. In the repair environment the requirements-supply recondliation helps to recon- 
cile requiren^ents and supply 

Manufacturing Supply Chain 

The PSI Planning Frame 160 supports the process that develops an integrated production-sales-inventory plan for 
a selected product groiif). The objective is to ensure that the resulting PSI plan 190 meets customer requirements and 
satisfies supf^ capabilrty constraints and the inventory objective of the company. The current PSI plan 1 90 is displayed 
together with a temporary PSI plan 190. The temporary PSI plan 190 can be irrported from various data sources 
(induding data series from Scenarios 78). The user can then ar^lyze and modify the temporary PSI plan 1 90 with easy 
reference to the current PSI plan 190. The user can replace the cun^ent PSI plan 190 ly the temporary one once the 
latter has been improved to satisfaction. 

The PSI planning process requires the support of three nrwxiules: the Sales Forecasting and Planning (SFP) Mod- 
ule 132, the Aggregate Production Planning (APP) Module 162 arxJ the Finished Goods Inventory Management (FGIM) 
Module 164. 

Forecast Recondliation 

The Derriand Managenient Franie 130 supplies the Forecast Data 146 (bo^^ 
indication of the rnethods used to generate thenrt The user can use the sanra rnethods to general 
conpare the forecasts generated by cftfferent methods. The user analyzes and reconciles these forecasts to generate 
an appropriate set of sales requirements. The PSI Recondliation 1 70. with the support of the SFP Module 1 32. revises 
forecasts and recondles top-down arxl bottom-up forecasts. 

Revise forecasts 

The forecast revision process acquires, cfisptays, analyzes and ecfits the bottonvtp or top^fown forecast The user 
first acquires forecasts generated using (Afferent m^hods from the Demand Management Frame 130. After analyzing 
ttiese forecasts and comparing the results, the vsef then selects the most appropriate one to be used. The foOowing 
features are identified for this process: Acquire and cfisplay forecasts; Check forecast errors: Compute and display 
related statistics of sales; and Select forecasts. Incfividual descriptions of these four features are as follows. 
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Acquire and display forecastsr^- * . - . . . ^^^^ ^ ^c- 

Ths feature consists of tfie following four steps: 

Choose product group: The user specifies the product group of Irrteresl 

Choose aggregation level: The user specifies the aggregation level (e.g. month, year) for data display 

Inport forecasts: The DSS 10 acquires the bottom-up and top-down forecasts generated in Demand Management 

Frame 130 for the selected product group from the DSS Datab^ 12. 

Display forecasts: The DSS 10 aggregates/d^ggregates as appropriate the foreca^ to cfisplay at the chosen 

aggregation level. 

Check forecast errors 

The forecast error checking feature supported by the SFP Module 132 conputes and displays various n-period- 
ahead historical errors of the bottom-ip and top^iown forecast 

Compute and display related statistics of sales 

The sales statistics computation feature st43ported by the SFP Module 132 corrputes: mean and variarice over a 
selected time interval, moving average, trend, and/br seasonality factors of any chosen sales line and display result in 
several forms (graphical, tabular or both). 

Select forecasts 

The foreca^ selection feature interacts with the Demand Management Frame 130 to check bottom-ip forecasts 
from various sources and the result of various top<iown forecast methods (e.g. moving average, regression, combina- 
tions, etc.) The user then chooses the most appropriate set of bottom-up and top-down forecasts based on their accu- 
racy, statistics and consister)ce with each other. 

Reconcile top^lcwn arxJ bottom-up forecasts 

The process of top-down and bottom-up reconciliation checks the discrepancy t>etween the two forecasts and if 
necessary, resolves the conflicts t>^een the two forec^ls to generate a more desirable sales forecast The following 
features are provided to support this process: Ckxrpute the difference between top-down and bottom-up forecasts: 
Generate weighted average of top<lown and bottom-up forecasts: and Manually overwrite temporary sales (S*) line 
(see the screens discussed later herein). Individual descriptions of these three features are as follows. 

Corrpute the difference between top-down and tx>ttom-up forecasts. 

The difference between top-down and bottom-up forecasts is computed and displayed to show the discrepancy 
between the two forecasts. 

Generate weighted average of topKfown and bottom-ip forecasts. 

The conflicts between the top-down ard bottom-up forecasts can t}e resolved by using a weighted average of t^ 
to generate a new temporary sales forecast in the S' line. 
Manually overwrite temporary sales (S*) line 

The user manually ovenm^ites the forecast on the S* line to adjust the sales forecast to reflect various considerations 
of influential factors. For example, adjust sales forecasts to accourrt for unrecorded or anticipated upcoming market 
changes. 

Inverttory Planning , . . . _ . . 

The process of Inventory Planning supported by the FGIM Motiu\e 164 and the Demand Management Frame 130 
deterrrvnes the f in^h goods inventory requirements. In inventory planning, the user first selects a product group. To he^ 
the user to select an appropriate inventory policy, the DSS 10 computes and displays various sales measures which 
characterize the sales pattern of the chosen product groups For example, a Min^ax poGcy might be appropriate for a 
product group facing steady demand. The DSS 10 then, based on the inventory policy selected by the user and the 
managerial sales and service targets, determines the poficy param^ers and inventory level requirements. The user can 
then nvxiify the policy param^ers and inventory level requirements to satisfy various managerial requirements and pro- 
duction resources Gmitations. The follming two features are identified for this functional requirement: Fommilate fin- 
ished goocte inventory pofides; and Determine finished goocfe inventory requirements. 
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Fbnnulate finished gcxxis inventory poT^^ -^.^ ^. — . 

The fomiulation of finished goods inventory policies involves the selection of inventory poGctes for chosen product 
groups and specifying the corresponding po5cy parameters^ It is broken down into the foDowing features: Choose inven- 
tory polides for product groups; Choose policy parameters; and Compute estimated inventory statistics. 

Individual descriptions of these three features are as follows. 

Choose invaitory policies for product groups 

In this feature, the user select inventory policies for product groups based on the patterns of sales the product 
groups are fadng. It involves the following three steps: Choose product group: The i^er specifies the product groip(s) 
of interest; Acquire the fotlcwing sales measures from the Demand Management Frame 1 30: Usage rate - fast medium 
or stow nxTving, Lumpiness - sparseness of significant denrtands. and Vblatility - coefficient of variation; and Select 
inventory policy: The user chooses among the fdlGwing an inventory policy for the chosen product group(s) based on 
the sales information acquired. 

For single product group with non-lumpy demancte: User-spedfied base-stock policy, P^odic review cost optimi- 
zation policy, and Period review nrxxfel with service level constraints. 

For related multiple product groups (&g. groups sharing the same proc&iction resources.) with non-lumpy 
demands: Leveled PoBcy, Syncfironized Policy, and Optimal Policy. 

For single product group with lumpy demand: Maximum n-Period Coverage Policy. 

Choose policy parameters 

The FGIM Module 164 based on the sennce level constraints arxl managerial objective (e.g. minimize inventory 
canying cost with a stock out probability of at most 5%) d^emiines the policy parameters to be used for the inventory 
policy chosen by the user. The user can then observe the results of the estimated inventory st atis tics and adjust the 
policy parameters as appropriate 

Corrpute estimated inventory statistics 

The estimated inventory statistics calculation feature supported by the FGIM Module 164 computes and cfisplays 
the following inventory r^ted measurements: average inventory level (as weeks of sales); expected stock-out proba- 
bility; service level (fill rate); inventory carrying cost and total co^ {i'>cluding production, inventory holding, stock out 
penalty and transportation costs) for the chosen inventory policy and policy parameters. 

Determine finked goods inventory requirements 

The FGIM Module 164 based on the inventory poficy and policy param^ers determines the finished goods inven- 
tory requirements for the product groups. The user can then mocfif ies the inventory level requirements as appropriate. 
The following features are identffied for detemrnning the finished goods inventory requirements: Compute and cBsplay 
inventory level at chosen aggregation level; Manually override inventory levels; and Ccxrpute arxJ display inventory level 
at chosen ag^e^on level. 

The PSI Planning Frante 160 stqpported by the FGIM Module 164 computes the inventory levels based on the cho- 
sen inventory policies and parameters. The result will be c§splayed in the temporary inventory (I*) line. If the computation 
is done at a lower aggregatfon level than the chosen one for display, the corresponding appropriate aggregation will be 
done before display. 

Manually override inventory levels 

The user can manually overwrite inventory levels to r^lect varfous managerial concerns. For example, the unavail- 
ability o# production resources at certain periods requires the decrease in con-esponding inventory levels a the sug- 
gested inventory level exceeds the given management target 

Supply RequirerTtent Planning 

The supply requirement planning feature supported by the APP Module 160 help d^emrtines the production 
requirenrients that are cons^tem with the sales ptan and the inventory requ^ It also checks the feasOMlity of the 

production requirements with respect to production capacity and component avaflability. In case of infeasftHlity, the 
feature win provide information about the cause of corresponcfing infeasfoility to the user. The user can then mocfiftes 
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sales requirements, increases available resources (production capacity or key component availabtlity) 'ancl/or prioritizes 
the sales requirements and restricts attention to satisfy a reduced set of high priority sales requirm^rts only in order 
to achieve fusibility. 

Determine production requirements to sustain sales 

The process of determining production requiremerrts to sustain sales consists of the following two features: Gener- 
ate production requiremerrts; and Manually overwrite the production requirements. Individual descriptions of these two 
features are as follows. 

Generate production requirements 

The production requirements generation feature supported by the APP Module 160 determines the production 
requirements based on sales and invmrtory requirements. There inventory requirements may take two different forms: 
Inventory levels, or Safety stocks. 

In case of inventory level requirements, the production requirements are generated i^'ng the inventory balance for- 
mula discussed herein. 

In case of safety stock irrventory requirements, the user can choose one of the follGwing objectives to determine the 
production requiremerrts: Minimize the maximum production capacity utilization; Minimize the maximum inventory level; 
Minimize the total inverrtory level; arxJ Minimize the total inventory cost (irrv^ory holding arxl t>acktog pertalty costs 
rec^ired). 

The production requirements generated are displayed in the temporary production (PO line. If result of sanity check 
is at a k3wer aggregation level than the one chosen for display aggregation will be done before display. 

Manually overwrite the production requirements 

The production requiremerrts are modified to r^lect various considerations. For example, insuffiderrt production 
resources during certain periods. 

Check aggregate production capacity & key component availat)ilrty 

In the process of checking the feasibility of sales, inventory and production requirements against the availability of 
production capacity and key components, the following features are identified: Define key components; Check sanity of 
a given set of sales requiremerrts On S' line) and saf^ stock constraints; Check feasibTrty of production requirements 
(in P' line); and Update and display productk)n capacity load arrd key componerrt availability. Individual desaiptions of 
these four features are as follows. 

Define key components 

Each user defines a list of k^ components, which is recorded and can be modified whenever necessary. The list 
of all cofTYXxrents which are sorted according to ttreir availabDityyUsage ratio ^ displayed to help the user to deline or 
modify the list of key components. 

Check sarrity of a given set of sales requirements (in S' line) arxJ safety stock (in T line) constraints 

The process of sanity check utilizes the capacity checking model in the APP I^Aodule 160 to help detemrrine the pro- 
duction requiremerrts for the given set of the sales requirements and safety stock corrstraints. Funhenrwe, the user can 
scope ttre capacity checking model appropriately through mod tf ication of: Location(s), Products or produ;t groups. 
Time horizon. Production b'rres, arrd Key comporrents. 

If the results of the capacity model are infeasble, critical under-capadtated production resources and key compo- 
nerrts are suggested to the user for further mocfifications. 

Check feasbility of production requirements (in P* Bne) 

This process checks sanity of a given set of production requirements against the producti(^ 
ponent availabDity. Th^ is also stqpported bf the capacity checking model in the APP Module 160. Similar to the previ- 
ous sarrity check descntoed atxxve, ttre user chooses the appropriate scope of the capacity checkirrg model arrd if it 
turns out to be infeasS)le, critical urxier-capacitated production resources and k^ comporrents are suggested to the 
user for further modffication. 
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-Update and cfisplay production - -^■--r-.^^r^.^--^^,r,,^-,^ 

After a few iterations of the sanity checks and capacity requirement acQustment the user can reach a feeble set 
of production requirements. The remaining available production capacity arxi components are updated and can be 
5 displayed if requested. The user can then accept a reject new production requirements based on the availability of pro- 
duction capacity and key components. 

Proc&iction-Sales-lnverTtory Plan Coordination 

10 The coordination of the production-sales-inventory plan ensures consistency among the production, sales and 
inventory plans and helps determine a feasible and appropriate PSI plan 190. 

Check and ensure consisterKy in PSI plan 

IS The user can utilize this feature in either: the independent mode or the consistent mode. 

In the former mode, the user can edit the production, sales and inventory requirements separately by dsregarding 
any cons^tency requirement. In the tatter mode, the DSS 10 always ensures the cons^ency of the production, sales 
and inventory requirements. In the consistent mode, the fotlcwing features are identified: Modify the plan according to 
the i^er defined sequence; Maintain the cons^tency in other lines due to the change of one line; Update the production 

20 (P), sales (S) and inventory (I) lines (see display figures discussed herein) by their corresponding temporary lines; 
Maintain consistency at different aggregation level (for either the consistent or independent modes only). Individual 
descriptions of these featires are as follows. 

Modify the plan accorcfing to the user defined sequence 

25 

When the user first switches to the consistent mode, two of the terrporary production, sales and inventory lines 
have to be selected to generate the third line using the inventory balance formula discussed herein. 

Maintain the consistency in other lines due to the change of one line 

30 

Whenever a terrporary production, sales or inventory line is ovenvritten, it will be modified together with one of the 
remaining two lines (pre-selected and can be re-selected anytime by the user) to maintain consistency. 

Update the productfon (P). sales (S) and inventory (I) lines by their corresponcfing terrporary lines 

35 

TTie user can replace the set of P. S and I display lines (see dsplay discussion herein) by a set of consfetent P\ S* 
andr lines. The P. Sand I lines can always be saved as a scenarkx Only user with the appropriate system privilege can 
savetfieP. Sand Itinestothe DSS Datafckase 12 permanently. 

40 Maintain consistency at cfifferent aggre^tfon level 

The DSS 10 can display data at any resolutfon higher than the primary data resolution level. Whenever display at 
a higher resolution is modified, dsaggregation will be done to maintain constetency. The DSS 10 computes a set of 
default disaggregation logic based on existing lowest resolution data The user can overwrite the disaggregatfon logk: 
45 whenever appropriata 

« - Evaluate PSI plan optfons 

The PSI plan options evaluation feature conputes and displays the performance metrics for various versions of the 
50 PSI plan 190 for the user to compare and choose a desirable one. The tbUowing two features are identified to support 
this feature: Corrpute relevant performance metrics; and Compare cfifferent plans. Individual descriptions of these two 
features are as folfows. 

Corrpute relevant performance metrics 

55 

The foDowing performance metrics are corrputed using the routines speciTied in the SFP 132. FGIM 164 and APP 
Module 160 to assist the user to select a more desirable versfon of the PSI plan 190: Total and breakdown of costs, 
Average inventory level. Average expected stock-outs. Expected Throughput Time, and Expected Senrice level. 
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>»'^Compare dffferent plans* - • *r -t^-;- ^ . — 

Different PSI plans 1 90 over the same or cfifferent time periods together with their corresponcfing performance met- 
rics are displayed side by side for conf7)arison purposes. 

Repair Environment 

In the Repair Environment the term "Requirements-Supply Recondliatjon" is used in place of Production-Sales- 
Inventory planning. This reflects the fact that there is no production nor sales in a repair environment but "repair require- 
ments'* and "repair supply" in the form of repair workstation capacity arxi corrponent availat>ility. "Requirements-Supply 
Reconciliation" Planning is a reconciliation process that develops an integrated arxi feasible plan. 

The Requirements-Supply Reconciliation comprises of two main processes: Estimation of the aggregate repair 
rec^irements based on the inventory position of serviceable parts at the repair location and the target level for this 
inv^itory; and Feasa>ility assessment for the aggregate repair requirements urxler resource capacity (skDte and work- 
stations) and component avaOabilfty constraints. To support these processes the following functional requirements have 
been d^ined. 

Evaluate and propose Consolidated Serviceable Inventory (CSI) Levels t>ased on past usage and future usage 
rec^irements. 

The follcMnng operations are performed: Refine variability and lurrpiness estimates of usage; R^ine repair lead 
time estimates; and Propose target CSI levels 

Determine Aggregate Repair Requirements 

This includes using target CSI levels, and current inventory positions to determine aggregate repair requirements. 

Generate Aggregate Repair Plan 

Thfe includes the following: Verify repair resource capacities to satisfy aggregate repair requirements based on; 
repair personnel skill sets; workstations features; Verify key component availability to satisfy aggregate repair require- 
ments; and Generate aggregate repair plan under capacity and component constraints. 

Supply Management 

The Supply Management France 200 supports the Suppfy Management decision process. 
Module and Data Space Association 

Figure 1 8 shews the participating modules and the associated data spaces for th^ Frame 200. 
Process Flow 

The process f k3w digram for the supply planning frame 200 is shown in figure 1 9. The Supply Management Frame 
200 stpports the following functional requirements kientified for the Supply Mar^gement decision process: 

Aggregate Productfon Planning 

The APP Module 160 works ctosely with the FGIM Module 164 and uses Inventory Data 182 and the Production 
Capacity Data 180 to evaluate production and inventory trade-offs. The APP Module 160 also uses the Production 
Requirements Data 174 from the PSI Planning Frame 160 to generate aggregate production plans. These are written 
to the Aggregate Productk>n Plan Data 202. 

Dynamk: Repianning 

The aggregate production plan is often mocfified by the APP Module 160 to reflect either changing production 
requirements provkJed by the PSI Planning Frame 160 through the Production Requrements Data 174 or changing 
corrponent availability from the hteterial Planning activity 210 through Material Delivery Schedule 212. 
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* Capacity Planning . r *- -tir -M-vc. .^ ^ 

The APP Module 160 utilizes long-term Production Capacity Data 180 from the Product Planning activity 214, the 
production parameters such as process times from Production Matrix 216. and the planning biD-of-material for the prod- 
uct from Planning BOM 218 to determine the production capacity requirements. In so doing, the APP Module 160 may 
evaluate a number of production capacity options such as various production line structures and allocation of 
resources. The capacity plan is written to Production Capacity Data 180. 

Conponent Procurement Policy Development 

The Component Procurement Policy Development (CPPD) Module 230 reviews the long-term component require- 
ments in Component Requirement Data 232 and other relevant component supply information to formulate component 
procurement policies. The component procurement policy parameters are then written to Componerrt Supply Contract 
234. 

Data Flow 

The data flow diagrams for the Supply Management Frame 200 are shown in figure 20 and figure 21 . The Supply 
Management Frame 200 generates the core report previously discussed, namely, the Master Production Plan 240 and 
the Production Capacity Plan 242. 

Vendor Managed Replen^ment Frame 

The V^idor Managed Replenishment (VMR) Frame 250 supports the VMR dec^on process. 
Module arxJ Data Space Association 

The Data Space associations for Frame 250 are illustrated in figure 22. 
Process Row 

The process flow diagram for the VMR Frame 250 is shown in fi^re 23. The VMR Frame 250 supports the func- 
tional rec^irements identified for the VMR decision process: 

VMR Strategic Planning. 

The VMR Strategic Planning activity 252 in concert with the MDA Module 134 and the FGIM Module 164 considers 
the financial and business requirements supplied by the customers. cSstrtxition infrastructure. POS history and the 
transportation factors in the Supply Chain Network data table 260 to evaluate various service contract options. The 
VMR contract parameters are ttien ¥fritten to VMR Contract 262. 

Replenishment Planning 

The Replenishment Planning activity 270 wortdng with the MDA 134 and the SFP Module 132 reviews ttie sell- 
through information and provides input to the FGIM ModiJe 164 to generate the corresponding replenishment require- 
ments. These requirements are r^ned according to the VMR Contract 262. Based on these inventory requirements, 
the VMR Contract 262 and the order futfSlment activity, ttie replenishment schedule is generated and written to VMR 
Data 272. 

Data Row 

The data flow cfiagram for the VMR Frame 250 is shown in figure 24. The VMR Frame 250 generates the Replen- 
ishment Schedule report 280 Gsted eartier. 

VM R, also referred to as drect replenishment, is a growir^ agile logistics partnershp agreement where the vendor 
takes on the resporisSMlity of rnanaging the inventory at the ojstonfier sites for i.a, monitoring, 

planning, and directiy replenishing the inventory in the customer's distr3)ution network. In other words, under a VMR 
arrangement it is the vendor who determines when stocks are to be replenished and in what quantities, rather than 
responcfing passiv^ to orders placed by the r^er. This arrangernent is usually typified by a contract which specifies 
the financial terms, inventory constraints, and performance targets such as service measures. VMR is almost invariably 
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based on the avanability of direct access to point-of-sale data and the customer's inventory positions. Such an anange- 
ntent can be mutually advantageous to the customer and the supplier. 

On the other harvl, VMR requires the integration of inventory and transportation planning processes of the sufiplier 
and the customer. Although much has been written in the general literature about VMR as a concept (ag., W^l-Marf s 
5 retationshps with its supplieis) there are few known quantitative nruxiels, if any. to support VMR. Existing VMR syst^ns 
are transaction oriented and provide little or no decision support capat^Oties. 

The VMR Frame 250 consists of a set of decision support tools that can t>e used in the development of VMR pro- 
grams. The features offered by the VMR Rame 250 support the decision nrtaking processes in the VMR programs at 
both strategic and operational levels. More specifically, at the strategic level, the user can invoke the features provided 
10 tjy the Franrte 250 to study of the feasbiDty of VMR programs: evaluate the terms of VMR contracts; and periodically 
review the overall performance of the VMR program. 

At the operational lev^, the user can invoke the Frame features to develop sell-through forecasts; obtain suggested 
replenishment quantities; revise replen^ment quantities; and nxxiitor sales and other VMR related statistics. 

In this section, we will provide the functional specification for the VMR Frame 250. The entire Frame 250 can be 
IS partitioned into three main parts: basic and VMR specif ic data maintenance, strategic planning and replenishment plan- 
ning. It supports the following two functional requirem^its: VMR Strategic Planning: Evaluate financial and logistical 
tradeoffs in a VMR contract, and Comparative analysis of various service contract options; and Replenishment Plan- 
ning: Review sell-through and determine inventory requirements at retailer's kx:atioa and Formulate ttie replenishment 
plan. 

20 The main decision nrxxfutes to support the VMR Frame 250 include MDA 134. SFP 132. VMR and APP 160. We 
win discuss the functional spedftcations that are applicatsle to the manufacturing environmerrt. 

Data Maintenance 

25 To support general functionality of the VMR Frame 250, the system should maintain two types of data: the Basic 
Structural Data arxJ the Replenishment Data. In the following two sut>-sections we d^cuss the details of these two sets 
of data. 

Basic Structural Data' 

30 

These include the essential data elements required to describe the basic characteristics of the products, distribu- 
tion network, etc. This set of data are relatively stable and require only infrequent updates (e.g., at the time when the 
VMR program is being initialized, or wlien new models are being added to the program). These include: 

35 Di^ribution Network: D^ine the customer as well as the v^xkx's product distrftxition networks that are relevant to 
the VMR program. It identifies which product is t>eing cfistributed from which vendor warehouse arvi which cus- 
tomer Distritxition Center (or store) are assigned to each warehouse. 

Distribution Center (DC) Profile: Define the main attrSxJtes of a customer DC or a vendor warehouse inducGng its 
kx^ation (dty and state) information. 
40 Lead-tinrtes: D^e the lead-time for product distribution between a given pair of locations and the corresporxiing 
transportatk)n modes. 

Transportation Costs: Deline the transportatbn costs for prodiK:t distrftxition for given transportation nrxxles. 

Product Profile: DeHne the main attributes of the products participating in the VMR program including thar IDs and 

physical characteristics. It also species whether a product is currently in the VMR program. 
45 Product Replacement Relatk>nship: Define the relationshp t)etween a cun-ent product and its predecessor (being 

repAacedi, This provides the basic inforniation to establish a coritinuousdernand stream for a pair of ck>sefy 
. ^ products. ^, , 

Replenishment Data 

50 

Replenishment data are rnore dynamic, and record the details about the replenishment activities as well as the 
characteristics of the VMR program itself. These indude: 

Product and DC Wktch List: A set of products and DCs that ared^ed by the user to be monitored tyy the system 
55 SO that any special nvivenients or activities can be detected arxf reported. 

Seasonality Factors: The set of factors cateulated by the system or provided by the user to characterize the basic 
seasonal f tuctuatk>n patterns in the sales activittes. 

Replenishmerrt Orders (Receipts, trvtiansit Incomplete, etc.): The detailed order status information that is 
recorded to capture the repler^hment activities included in tfie program. 
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— - Maximum and Average Inventory LeveterThe targeted maximum and av^ge inventory-levels specked in the VMR 
contract They can be used to monitor ttie cun-entperlbnnanceof the VMR program. 
Service Levels: The targeted customer service levels specified in the VMR contract 

Delivery Rec^ency: The deGv«y frequency is d^ned by the usa^ or the system and it specifies the frequency at 
5 which the products are replenished for a particular customer DC. 

Promotion Calendar: The calendar captures the relevant promotion activities. This information is then used to 
ensure tfiat a sufficient additiona] amount is included in the regular replenishment quantity. 

Strategic Planning 

10 

Strategic planning features mainly support VMR dec^ions during the initial program setup; important during VMR 
contract negotiation stages. They are also useful to provide critical operating parameters, e.g.. replenishment frequen- 
cies. Finally, they are also needed to conduct long-term performance reviews. Therefore, the functions provided at the 
strategic level are addressing tfie issues which are of long-term inportance, even tfK>ugh these decisions are not made 
IS so frequently. 

VMR Contract Setup 

During the initial stage of potential engagement in a VMR program, the conditions in the VMR contract are pro- 
20 posed, studied ar^j negotiated. Under such drcumstarKes, the user needs to evaluate the costs and benefits of many 
different program options. When the terms are conflicting, tradeoffs have to be mada In additioa one also has to 
choose a set of operating parameters and procedures which optimize total cost measures while sattefying given con- 
straints. The features provided Man are to SLf)port these decision making problems. 

For a product/product group, a customer DC, and a delivery frequency defined by the user, the system will provide 
25 the corrputed relationship between expected service level arxl maximum (average) inventory level. Such a relationship 
wiO also be useful for the user to evaluate what-if Scenarios and can be used in other features in tfiis Frame (e.g.. tiie 
Replen^ment Planning below). 

Compute arxJ cfisplay expected service level for the maximum inventory requirement d^ined by the user. 
Estimate and display the proper inventory level for a given service level defined by the user. 
30 When evaluating the optimal VM R operating parameters or conditions In the contract the system can help the user 
to either check the compata^lrty of a set of constraints including service level, inventory level and delivery frequency, or 
select an optimal set of these parameters after the evaluation of all feasa)le combinations. 

To use this feature, the first needs to choose the product/product group and the DC of interest. 
For a given replenishment scenario (a given set of delivery frequency, target inventory level and customer service 
35 leveO, tiie system will estimate the total cost including customer DC inventory carrying cost transportation cost and 
manufacturing plarrt inventory carrying cost. 

Different replenishment Scenarios can be generated based on diff^ent values of delivery frequency, target average 
inventory level and target customer service level. In order to compare these cfifferent options without using total pro- 
jected costs like the one suggested in the feature atxve, the system wOl compute key s ta tistics such as expected invert- 
40 tory levels at customer DCs and nmnutacturing plants. By corrparing these statistics, a better replenishment scenario 
can be identified. 

Contr^ Parameter Monitoring and VMR Program Review 

45 After a VMR program has been setup and tfie eocecution started, it requires constant monitoring of ttie key policy 
parameters and performance measures. If there are sut>stantial chartges, it is critical to report them back to the users. 
This is because tfie optimal operating parameters in the VMR program set at the strategic level are obtained under cer- 
tain assumptions atx)ut tfiese key incficators. In adcfition, periocfically, the rranagement will t>e interested in the actual 
effectiveness of the VM R program. To support such pro-am reviews, the system will record and generate management 

50 reports regarding the actual performance of tfie VMR program compared to the inventory arxi customer service level 
targets set in the VMR conti'act. 

Perioctically (wfu'ch can be d^ned by tfie user), the system will compute the mean and standard deviation of the 
sell-through for a given product of a given customer DC. The resultirtg mnrbers can then t>e compared to the historical 
normd^ned by the user, the quantitative modefing assurnptions, or recorded by tfie system. If the mean and standard 

55 deviationareoutsideof the defined range, then ttie user has to be informed through a proc^ 

or other similar reports. The user wfll be asked to define tfte foDowing: Requency of such evaluatkxi; Historical norm of 
tfie mean and standard deviation: and The ranges of the mean and standard cteviation. 

(>ie of tiie key objectives of any VMR program is to reduce the total inventory levels at differ 
chain. The system wQI compute and record average inventory levels and compare it to maximum and average inventory 
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targete. The results can th&i1>e rep(>ited to the user as requeste^^ ' * o--r'\w.-t- ai-x:- . • 

When the inventory level of a given product^oduct group at a custonner DC is mujch higher than needed, part of 
the inventory should be considered as excess. The system will report tfie list of products whose inventories are in 
excess. These products then will be off the replenishnnent product list until the inventory levels return to a nomrial range. 
5 During these periods, fhe production and nnany other logics operations planning wiD have to be notified atx)ut the 
reduction in planned quantities. 

Replenishmerrt Planning 

10 ihis is to support nxxe operational decision problenns on a regular basis after the VMR program has started its exe- 
cution. During this stage, the main concerns of the user will be sfiifted to those of a more operational flavor such as tiie 
generation and revision of the replenishmerrt order to satisfy target customer service levels arxi maximum inventory 
constraints. In adcfition. in order to ensure the validity of the decision support modete and prepare the decision makers 
for changes in tf^ maritet place, the system will nrxxiitor certain operational incficators relating to the VMR program. The 

IS indicators and purpose of this monitoring are cfistinctively different from tfie monitoring and review function offered at 
the strategic level. . 

Sell-through and Demand Orientation Forecasts 

20 Before we can start to use the system to generate replenishment orders, a set of sell-ttirough forecasts have to t>e 
developed. We will use the models developed in SFP 132 using POS as the primary data source. On the other harxJ, 
the production planner at the manufacturing vendor needs to know longer term forecasts to plan for future capacities. 
To that end. the system allcws the user to devefop and examine not only the replenishment quantity of the next replen- 
ishment cyde but also to extend several periods ahead so ttiat tfiese longer term forecasts can also be estimated and 

25 used for other (e.g.. manufacturing) planning purposes. 

Based on the sell-through data provided by the customer for a given productyk>roduct group at a customer DC. the 
system will generate sell-through forecasts including mean arKi standard deviation for any given product at a customer 
DC. The actual forecast algorithm will invoke an appropriate one specified in the SFP Module 132 which should con- 
sider trend, and seasonality anfK)ng other basic aspects of the data stream. In case of a product having too littie sell- 

30 through history, the system will use the product replacement relationship d^ined to establish nx>re continuous sell- 
through history. In addition, the system will also permit the user to select an appropriate length of historical data to 
account for abrKxmal sales activities for the product. 

The system will also g&ierate longer term replenishment requirements for the demand orientation for a given prod- 
uct so tfiat tf)e user can plan for the longer term demands for the product. To generate mecfium to long term forecasts. 

35 the system will first forecast the sefl-through for the specified time periods by invoking appropriate forecastir)g algo- 
rittims in the SFP Module 132. Then, a set of replenishment quantities wiD be generated using the replenishment algo- 
rithm in the VMR nrodula These replenfehment quantities will then k>ecome the demand forecasts for tf>e product 

Replenishment Order Generation 

40 

The generation of replenishment orders is the main functionality of the replenishment planning of the VMR Frame 
250. The main objective of the functionality is to provide the user with an initial set of replenishm^ quantities for a set 
of products with the consideration of the sell-through forecasts as well as VMR specific operating parameters. The 
quantities will then be approved by the user and converted into actual purchase orders. 

45 Based on the forecasts of the future &el(-through. user defined VMR operating paranteters (ag.. customer service 
level, maxinruim inventory level and delivery frequency), and olher related indicators (ag., last reported customer DC 
inventory level), the system wiQ generate a suggested replenishment quantity for a future replenishment data 

If the product rrxxlel year changes are regular, then it is necessary to treat the replenishment quantity needed for 
product (or VMR program) initialization and ternvr^on differently from the regular replenishments. Therefore, the 

50 atx>ve feature has to t>e rrxxj^ed to t>e appBcatDle to these setting: 

Set Initial Replenishment Quantities: The main difference between the initial replenishment quantity setup arxJ the 
regular one is that it nriay require adcfitiorial quantities to fiUcustonrier DCs or st^ In adcfition, because tfiere is 
no sell-through history available for these new products, the history for the replaced products wfll trave to be used 
55 in the computation. It is also necessary to set a time frame for the oonrputation algorithm to use a new products 
data wfien it accumulates erxMigh (tela of its own. 

Balance-out at the End of a Season: At the end of a selling seasoa a product needs to be phased out In such a 
situation, tf^ system wfll not generate any further replenishnr^ quantities for tfie product unless the user decide 
toGvenwritethe suggested (zero) quantities for a special reason. 
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For a given customef DC. when the products are being considered tor replenshment the system wilt help the user 
set joint replen^hment orders so that the total cost for the replenishment batch can be minimized. The basic logic Is to 
add or delete products induded in a replenishment batch to optimally use the transportation means wtiile maintaining 
satisfactory customer service level and inventory level. 

The system will also automate the replenishment quantity generation for a set of products selected by the user. 
This feature ^ useful especially when the number of products in the VMR program is relatively large and the user pre- 
fers to work only on exceptional issues rather tfian examining the details of each product*s replenishment activities^ 

Replenishment Order Revision 

After the initial replenishment quantity has been generated for each product the user may be intere^ed in exam- 
ining the entire or only a selected set of products to sure that the soft information can be reflected in the actual 
replenishment orders. In adcfition. a number of constraints such as product availability and production capacity will also 
have to be taken into consideratfon. The objective of the features listed below is to h^p the user revise the replenish- 
ment orders with reletmnt analysis arxJ search support tools. 

The user can def ine a set of exceptfonal report generation criteria so that the system can search for and display the 
prodiK;ts falling into the rang& The sample user-defined crrteria will include 

Mean and starxlard deviation exceeding certain Hmits of the historical nam 

The customer DC inventory exceedng the maxinuim inventory level after the suggested replenishment quantity 
arrives 

For a given replenishment quantity (either recommended by the system or input the user), the system wiD esti- 
mate and display the probability of stock-outs. To compute the profctability value, a search algoritfim is needed in addi- 
tion to the relationsh^} between inventory quantity, customer sennce level and delivery frequency. The user can use the 
feature to evaluate whether the replenishment quantity suggested is satslactory or not 

Most of the replenishment quantities discussed here are appropriate for non-pronx^onal sales. When a pronxstion 
for a product planned, the user should t>e informed so that the final replenishment quantities can incorporate addi- 
tional quantities due to the pronrxjtion. The objective of th^ feature is to identify pronrxition events during a given replen- 
ishment review period and help the user incorporate atWitional quantity for ttie events. 

Before the replenishment orders can be finalized, the DSS 10 will make sure that the vendor can supply the 
required quantities in the specified time frame. If tiie replenishment order shipment date is close to the review date, ttien 
the product (finished goods) availat>ility will t>e checked; and if the shipment date is further into the future, ttien the pro- 
duction capacity will be examined. 

In order to property make tradeoffs between different replenishment Scenarios, the system v^ll estimate ttie total 
cost (including the inventory and transportation among others) for a given set of replenishment quantities. The cost will 
be corrputed automatically as the user is making mocfifications in tfie repl^ishment orders. 

To reduce ttie transportation cost, a rough-cut trucktoad planning tool will be provkJed to the user so that tfte room 
left on a truck can t>e fated by other most-needed products for the same customer DC. The underlying logic is to buikJ 
a truckfoad of shipment whenever it is possSila 

Sales Activity Monitoring and Replervshment Review 

The movement of product sates reflected in the sel^through data will have different impacts on the future replerv 
ishment activities as welt as tfie m^hods used to generate recommerxied replenishment quantities. Therefore, the sys- 
tem will provkJe the monitoring and tracking capabilities for the user to better manage ttie sales changes. In addition, 
ttie operating parameters specified in the contract will also be monitored so that ttie user can be renrtinded whenever 
tfie replenishment quantities are likely to exceed the limits in the contract 

The system wilt compute and nriaintain the histork:al norms of nrieana^ 
tfiey can be compared to ttie similar quantities in the most recent periods It is an incScator of substantial sales cf^nges 
if ttie recent sales deviate from the user specified ranges of the historical norms. 

The system will monitor whettier the suggested replenishment quantity is going to exceed the maximum inventory 
level allowed in ttie VMR contract The user wflt ttien be notified to take further action. 

On a regular basis, the system will record a set of tracking signals and compute forecast errors so that when sut>- 
stantial changes occur, it should be reported back to the user to take furtiier action. 

Distrfoution Network Design 

The Distrftxjtion Network Design Frame 290 SL|)ports the Distrfoution Network Design. 
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Module and^Data Space Association - vi - - - -,vir^ >9..i.T=^ , . . 

Figure 25 shows the participating nrKxJules and the associated data spaces tor this frama 
5 Process Flow 

The process flew diagram for the Distribution Network Design F=rame 290 is shown in figure 26. The D^trilxjtion 
Network Design Frame 290 supports the functional requirements identified for the Distr^on Network Design decision 
process: 

w 

1 . DistritxJtion Ljocation Analysis 

The Rnished Gkxxts Network Design (FGDND) Module 292 works with the MDA Module 134 and the SFP 
Module 132 to develop a forecast of aggregate long-term demand which is then used to evaluate potential D^- 
Ixjtion Center (DC) locations. The chosen DC locations are then written to Inventory Node 294. 
75 2. Distritxition Network Optimization 

The FGDND Module 292 works in concert with the FGIM Module 1 64 to optimize the overall network configu- 
ration. The result of thfe optimization is the assignment of demand nodes to DCs and the assignment of production 
nodes to DCs. This information is tfien written to Supply Chain Network 296. 

20 DataFtow 

The data flow diagram fa the Distrbution Network Design Fiame 290 is shown in figure 27. The D^lribution Net- 
work Design Frame 290 generates two of the core reports listed earlier, namely, the Ci^omer-DC Assignment 300 and 
the Supply-DC Assignment 302. 

25 

Model Engine and the Modules 

In this subsection, the overall design of the Model Engine 20 is introduced. Ttie objective, scope, and features of 
the seven constituent nxxiules of the Model Engine 20 are discussed. 
30 The Model Engine 20 consists of a lit>rary of specialized quantitative models and analysis routines. To address the 
needs of a set of users, a Decision SLf>port Frame calls and assembles these models and analysis routines with the 
appropriate data. 

The number of models and analysis routines within the Model Engine 20 could t>e quite large by virtue of the nrxxJ- 
utar design and inherent complexity of the DSS 1 0. To better manage the Model Engine 20, there is a need for logically 

35 grouping the modete and analysis routines. Furthermore, these nxxlels and analysis routines support major dedsion- 
nnaking areas in a supply chain. Therefore, the nrxxJels and analysis routines are grouped into seven nxxiules corre- 
spondng to the prindpa) decision-making areas in the supply chain as shown in figure 28: Market Data Analysis (MDA) 
134; Sales Forecasting & Planning (SFP) 132; Venctor Managed Replenishment (VMR) 252; Rnished Goods Inventory 
Managenrent (FGIM) 164; Aggregate Productfon Planning (APP) 162; Component Procurement & Policy Devetopment 

40 (CPPD) 230; Rnished Goocte Distrfoution Network Design (FGDND) 292; A frame by virtue of its delinrtion may require 
the participation of some subs^ of nxxiules (i.e., the nrxxfels and analysis routines of these nrxxlules will be involved). 
In the case of the PSl Planning Frame 160, the MDA 134, SFP 132, FGIM 164, and APP 160 Modules will be involved 
in constituting the dectsfon logfo 76. 

In many cases, the same nxxlels and analysis routines may be empfoyed by distinct frames in different contexts, 

45 where the relationships between the models and the associated data linkages vary oxxMdingly. This requires that the 
Supply Chain Frame Manager 24 interact directty with the nxxtels and analysis routines in the Model Engine 20. The 
nrxxlels and analysis routines will therefore have standard (tefta and fogic irputfoutput (I/O) formats. The standard MO 
formats will also facilitate the maintenaru:e of the irxfividual models arxi analysis routines, e.g., updating arxj replace- 
ment. 

50 In addition to the seven nxxiules defined at)ove, there is also a ^oup of general purpose numerical routines that 
are not specific to any of the dtxive seven nxxiules. These routines are collected into a design element refen^ed to as 
the Model Engine Utilities 22, as shown in figure 1 . Examples of tf>e Model Engine Utilities 22 irKlude generic linear pro- 
gramming solvers, and statistk:al analysis routines. 

Table 7 lists the nxxiules in the DSS architecture for the two supply chains. 

55 
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Manufacturing Supply 
Chain 


Equipment Repair Supply 
Chain 


Market Data Analysis 
(MDA) 


Market Data Analysis 
(MDA) 


Sales Forecasting & 
Planning (SFP) 


Sales Forecasting & 
Planning (SFP) 


Finished Goods 
Inventory Msmagement 
(FGIM) 


Finished Goods Inventory 
Mcuiagement (FGIM) 


Aggregate Production 
Planning (APP) 


Aggregate Production 
Planning (APP) 


Component Procurement & 
Policy Development 
(CPPD) 


Component Procurement & 
Policy Development (CPPD) 


Vendor Managed 
Replenishment ( VMR ) 




Finished Goods 
Distribution Network 
Design (FGDND) 





Table 7 

Modules in the Manufacturing and Equipment 
Repair Supply Chain 



Market Data Analysis (MDA) 134 

30 

The MDA Module 134 contains quantitative models and conputational routines that compile arxi synthesize hybrid 
sources of market information to support Sales Forecasting & Planning, and VMR. The models and routines of the MDA 
Module 134 are used in support of Demand Ghar^erization, Bottom-up Forecasting. Top^Jcwn Forecasting. Sales 
Promotion Analysis and Vendor Managed Replenishment The modete and the routines in this module are used to: 
35 Analyze relevant industry data from various sources; and ProvkJe quantitative analyses of sales. 

Scope and objective 

Objective: ConpQe and synthesize hybrid sources of market information for tfie purpose of sales forecasting and 
40 planning, and VMR. 

Scope: Industry-wkie. company spec^ and point-of-sale data. 

Features: Analyze relevant industry data from sources such as Nielsen and EIA (Electrorucs Industry Association); 
Devek)p customer and customeryjxoduct profiles; Maintain promotion calendars of major customer and tfie enterpr^; 
analyze promotional effects; and Provkf e quantitative analyses of sales at retail outiets whenever point-of-sale data are 
45 availabia 

Demand Characterization 

The models and routines in the MDA 1 34 module to support demand characterization in the commercial setting are 
50 equally appticat)le to support requirements characterization in the defense setting. 

For national defense applcations, the actual repair item usage data conespond to the POS Data 138 in the com- 
mercial setting. Analysis for POS Data 138 can be performed on the repair item usage data to c^ 
various parts. Furthermore, in order to intuitively access relevam repair item-related data and information 
ship among different parts has to be e^ablished. To that end. we will develop a tree structure to represent the b'll of 
55 material where each node of the tree corresponds to a repair item, and each arc represents a parent-chiM relationship. 
For ease of presentation we empfoy commercial nomerK:lature in the foDowir^ sectioa 
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AnalysfeFtoirtines for Denmxj Characterization ^ . - — 

In the fbllowing, we descrO^e three types of analyses that will be performed on industry survey data. Demand His- 
tory Data 136. and PointOf-Sales Data 1 38 to characterize the demand for the products (or sendees in defense appG- 
cations). There are ether types of analysis that can be performed on these data sets which wfllt>edscus^ 
when each individual data set is being considered. 

Product Family Conposition Trend and Percentage 

Ths involves the analysis of the trends in quantity and percentage of each product family over a given period of 
time of the time series. The irput of the analysis routine is the set of time series corresponding to tiie product families 
and the associated product family names. The output is the trend of the quantity, and composition percentage for each 
individual product family. For exarrple, Table 5 t>elow provides the percentage changes for major color television prod- 
uct iamaies (IS^-U", 15"-24", 25", 26" and 27* & above televisions) from 1988 to 1994. 



13-- 15"- 25" 26- 27" + 


1988 


24.76% 


55.87% 


6.05% 


1.14% 


6.18% 


1989 


24.98% 


54.86% 


7.28% 


^.oii 


7.87% 


1990 


22.12% 


54.79% 


8.06% 


4.56% 


10.47% 


1991 


23.08% 


49.53% 


10.53% 


3.90% 


12.96% 


1992 


20.62% 


48.18% 


13.29% 


3.40% 


14.51% 


1993 


19.13% 


45.12% 


15.87% 


2.10% 


17.78% 


1994 


18.57% 


41.58% 


17.58% 


1.55% 


20.71% 



Table 8 

Sample Product Family Composition Change from 1988-1994 



Pareto Analysis of Sales 

The analysis invokes the plotting of the percentage cumulative sales levete vs. the percentage of total number of 
products to determine the ABC dassrftcation of each product as illi^lrated in figure 29. 

Objective 

To identify the products or customer that contrftxjte the rTx>st to the overall sales or production volume. To establish 
the ABC classification of products (or customers). 

Input 

POS Data 138. Shipment or proc&iction data. 
Output 

Plot of the cumulative percentage sales (or production) levels vs. the percentage of total number of products or cus- 
tomer generating this sales (see figure 29). 

Algorithmic Steps 

Rank products or (customers) in deae^ng order of sales. 
Starting from the top of the 6st compute: 

cumulative sales 

cumulative number of product (or customers) 

Plot percentage of cumulative sales as a function of percentage of total numt)er of products (or custoniers). 
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In addrtion. another scatter plot can be drawn to shew the volatility vs. sales (where measure of the volatility is the 
coefficient of variation) as shown in figure 30. Each point in the second plot corresponds to a product (or product family), 
and the result of these two plots can be used to develop differentiated inventory control policies for products with differ- 
ent demand patterns. 

5 

Conflation Analysis Anx>ng Protect Fanrtilies 

This involves the analysis of the con-elation among the time series corresponcfing to different product families. The 
irput of the analysis routine is the set of time series con-esponcfing to the product families and the associated product 
10 family names. The output is the correlation coefficient for related product families. 

Indi^try Survey (EIA) Data 

Bectronics Industry Association (EIA) coDects manufacturer to retailer Demarxi History Data 136 monthly from all 
15 major consumer electronics manufacturers. After consofidation by EIA. the are sent k>ack to the manufacturers for 
their own usage in analyzing industry wide seil-in activities. The data may be obscured by temporary stocking and other* 
short-temri dealings between individual manufacturers and refers, and th^ are i^ually a few months lata Therefore, 
the data are normaDy not suitable for short term dennand characterization and forecasting. However, for longer term, the 
data are useful in revealing trends and charges in the sales of overall and individual product families. The three types 
20 of analyses descra>ed herein can t>e performed on the EIA data to monitor the long-term demand level and composition 
changea 

Demand History Data 

25 Not all retailers are capable of collecting and providing the POS Data 138 to their manufacturer suppliers. For this 
reason, more traditional Demand History Data 136 should be analyzed to characterize the demarxi for the manufac- 
turer's products. We realize that the demand data are a r^lection of the customer demand but th^ can t>e altered by a 
number of factors. For instance, meeting the quarter-end sales target or taking advantage of temporary sales promotion 
deate may make true consumer demand for the products less apparent. Nevertheless, the Demand History Data 136 

30 are an important source of demand information tfiat can complement the short term demarxi information from the anal - 
ysis of POS Data 1 38 and tfie bng term dennand information obtained from EIA data. In general, Demand History Data 
136 are wore sultak)le to analyze the medium term sales level and trend information. The three analysis routines 
described herein can be applied to the Demand History Data 136 to derive the medium term sales level and trend 
cfiange information. 

35 

Pdnt-of-Sales (POS) Data 

^teior rulers are new collecting tfte sales transaction data from tiie scanners at tiie sales counter and sending 
tfie data to their manufacturer suppliers after summarization. The data cfirectly r^lect the consumer demand for tiie 

40 manufacturer's products and response to sales promotions. They can serve as signals to the changes in sales trend 
and consumer reactions to marketing efforts. In essence, the POS Data 138 can be used to detect short term sales lev- 
els and their changes for the manufacturer's products at various retailing outiets. The three types of analyses descrft>ed 
herein can be F>erformed on the POS Data 1 38 to monitor the short term demand levels and their ongoing changes. 
The inventory status represented in the POS shouU t>e verified in order to be used to assess the supply chain fin- 

45 ished goods inventory situation. Shipment quantities from tfie manufacturer to the retailer are determined by consumer 
demand, and retailer's inventory carrying pofides. among other influential factors wfiile the POS Data 138 are nnuch 
nrxx-e direct in reflecting the true consumer demand. The folkywing three analysis routines will t>e applied to POS Data 
138 in addition to the three general ones mentioned herein. 

50 Inverrtory Status Verifk^ation 

To verify the inventory status, the POS Data 1 38 can be used in combination with the shipment data, arxi the inver>- 
tory balance equation to compute the deduced inventory status. Then, the deduced inventory status can k>e corrpared 
to the reported inventory status. 

55 

Inventory Proffle 

The inventory profile corresponds usiaOy to the management decision of an or^ization. and can be used to 
judge the ever- and under-stocking situation akxig the supply chaia The normal inventory profile for each product and 
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- customer combination will be-captured and^^stored so that rt can be later retrieved and compared to the current and^^^^^ -nrt^.- 
future (projected) inventory profiles to determine the poss&le over- and under-stocking situations. 

Detection of the Changes in POS Data 

The namal sales levete and associated variance intervals can be either calculated from the POS Data 138 for a 
given product by a customer, or specified by a user who is knowledgeable abou\ the sales activities for the product. 
When the sales level fluctuates beyond the normal sales variance intervals, the tool can detect and report the excep- 
tions automatically. 

Volatility of demand 

Objective 

To measure the volatility of demarxi. The volatility of dernand can be measured by the coe^ 
demand. The codfksent of variation of a random variable is equal to the ratio of the starviard deviation to ttie mean. A 
large value of the coefficient of variation indk^ates that the standard deviation is larger than the mean; the demarvl is 
therefore very volatile. While a small value of the coefficient of variation incficates a stable demand (low levels of vola- 
tility). 

Input 

POS Data 138 or Shipment data by product (product group) or customer (customer group) 

25 Output 

Volatility measure Cs- 
Algorithmic Steps 

30 

Compute mean of demand: 



35 




Corrpute starxlard deviation of demand: 

40 



45 

Compute coefficient of variation: 




Lunrpiness of demarxJ 

55 

Objective 

To measure the level of lunpiness of d&nand The tumpiness is a measure of the time dispersbn of demand. A 
dernand pattern is said to be lunrpy when the denriand is concentrated in only a fe^ 
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*r^:^- rous periods wrth no demand.' i*.,,^-.^ . . . . 

Input 

5 POS Data 138 or Shpnnent data by product (product group) or customer (customer group) 
Output 

Ci the lumpiness measura 

10 

Algorithmic Steps 

= the percentage of the total number of time periods with demand equal zero. 
15 Demand patt^ changes 



Objective 

To detect rapid changes in level and variability of sales. 
Input 

POS Data 138 or Shipment data by product (product group) or customer (customer group). 
Range for "normal" sales level arvl variability. 

25 

Output 

Exception signal indicating a normal change in sales levels. 
30 Algorithmic Steps 

Compute normal sales levels and associated variance from the POS Data 138 for a given product tjy a customer. 
Attematively user sets range for normal sales level and variability. 
Corrpute actual level of sales and variance each period. 
35 When the sales level fluctuates beyond the rK>rmal sales variance intervals, defect and report the exceptions. 

Demand history trend 

Objective 

40 

To characterize demand by trend and level parameters. To assess changes in the dynamics of demand based on 
. changes in trend. 

Input 

45 

POS Data 138 or Shipment ctela by product (product group) or customer (custonrier group) 
Output 

50 Estimation of trervJ and level. 
Algorithmic Steps 

For variable Xf ever time perbd 1=0 to a 

55 
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Compute trend'(b) andJevel (a) param^efs: 



15 



(i3 + l) 



70 



a2=[X-2?(n+l)/2]/ 



6 4 



MODEL 


WHERE USED 


Volatility of demand 


Demand Characterization 

PS I 

VMR 


Lumpiness of demamd 


Demand Characterization 

PS I 

VMR 


Demand pattern cheuiges 


Demand Characterization 
Bottom-up Forecast 
Top-dovm Forecast 
VMR 


Demand history trend 


Demand Characterization 


Pareto analysis 


Demand Characterization 
PS I 



20 



25 



30 



Usage of MDA Models 



Sales Forecasting and Planning (SFP) 132 



35 The Sales Forecasting and Planning Module 132 contains all the nxxJels and routines that are used to generate 
forecasts. These models and routines are used in the Demand Management Frame 130 for Bottom-ij|>. Top-down fore- 
casting, for the analysts of sales pronrK7tk)ns and to estirnatefaec Module 132 is also used in the 
VMR Frame 250. 

The models and routines of SFP 132 fall into three categories: generic models common to the manufacturing and 
40 repair environments; nxxjels specific to the manufacturing environment; and models specific to tfie repair environment. 



Scope and abjective 



Objective: Develop tcp-dcwn and bottonrvup sales forecasts. 
45 Scope: Products and selected customers. 

Features: Statistical forecast based on historical sales; Statistical forecast based on point^rf-sale data if warranted; 
Custonrfer provided forecast and orientations; and Recondliation to^ 
tion flags and sanity checks. 



50 Models Convnon to Manufacturing and Repair Environments 



Three types of generic models are common to the manufacturing and repair environments. The first type consists 
of the various statistical forecasting models that can be used to forecast any time series (demand or consoGdated 
requireiTiem). The second type concerns the estinriation of seasonality factors 
55 repair and the manufacturing environments. The third type of model relates to forecast accuracy estimation. 



Statistical Forec^ Models 



The ot3jective of the Statistical models is to generate a forecast based on the prelection of some historical charac- 
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10 



15 



20 



teristics of the time series. These modete can be applied to any time series In the context of demand characterization, - -s'- ^ . 

bottom-up. top^iown forecasts and VMR. 

Below we discuss the foDowtng models: Moving average: Lin^ trend: Exponents snvxithing: Hott- Winters nwdel: 
Winter's method: Regression based forecasting nrxxiel: and Autoregressive/moving average nfKxiel (Box Jenkins). 

Moving Average 

This conventiona] nrvxJel is appropriate when the dependent variable Is assumed to fluctuate around a constant 
(stationary) average value, i.a: 

Xj = p + e^.t = 1.2.... 

where p is an unknown constant corresponcfing to the mean of the series and £t Is a random error with mean zero and 
variance a^. Moreover, the model assumes that the variables {ej and hence { XJ are independ^ 



Input 



Time series data to be forecasted (for exanrtple POS or shipnrtent) 
Window n: number of periods to be cornered for averaging. 



Output 

Future forecasts and their variances. 
25 AlgorithrTBc Steps. 

Conrpute next period forecast based on the average of the last n periods 

30 

35 Estimate for c?^ : 



40 



45 

Linear Trend 



var (F,^i - X,^i) = o^(rH.1)/n. estimated by a^((r>+1)yh) 



This conventional nxxjel is appropriate when the dependent (forecastable) variable is assunDed to fluctuate around 
a trend line, specified as a linear fornwlation of time; l.a = a + b.t+ e , where e, Is a random error with mean zero and 
50 variance o^. As above, {e^ } and hence (XJ are assumed to t>e Independent The nrxxiel may be viewed as a special case 
of the regression t>ased nrxxlels befow. with 'time' as the only explanatory variable . 

Input 

55 Time series data to be forecasted (for exaniple POS or shipment) window n. 
Output 

Future forecasts and their variarx^es. 
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- -Algorithmic Steps. - - - - 

Select appropriate time period for trend estimation (the "window" of n periods). 
5 Compute trend and level parameters: 



70 



(13^1) 



15 



20 



25 



30 



35 



40 



a2=p-i>(n+l)/2]/ 



6 4 



Estimate forecast t>ased on trerKi projection 



Estimate variance of forecast 



F,+i=a*b(t+1) 



Exponential Smoothing 



This conventional model ^ appropriate when the dependent variable is assumed to fluctuate around a constant 
(stationary) average value, i.a: 

X, = p + E,,t = 1,2.... 
It puts progressively smaller weights on nrare remote observations from the past: 



F,^^ = aX, + a(1-a)X,.i + a(1-a) X|_2 + .... 



Input 



Time series data to t>e forecasted (for example POS or shipment) 
45 SnfKX3thing parameter a 

Output 

Future forecasts and their variances. 

50 

Algorithmic Steps. 
Initiate F-i as Dq. 

55 F^i=aD,+(1-a)F,. 
Estimate variarK:e of forecast 
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5 

Estimate variance of foreca^ error = Var (F - = (a^) ^/(2-a) 

Hott-Winters mod^ 

10 This conventional mode! also appropriate when the dependent (forecaslable) variable ^ assumed to fluctuate 
around a linear trerxj line, i.e. when Xt is specified by: 

X, -a + b.tf e, 

15 with the associated ^sumptions regardir^g e. As with exponential smoothing, progressively smaller weights are attrib- 
uted to more remote observations. 

Irputs 

20 Time Series Data to be forecasted (for example POS or shipment). 
Smoothing (>arameterB 1 >a^>0. 

Outputs 

25 Future forecasts and their variarx^es. 

Algorithmic Steps 

Initial So and Qo. intercept and sicpe of trend line. 
30 Update recursively 

S, = ~aX, + (1-a)S,.i+Gj.i 
G, = p(S,.S,.i) + (1-p)G,.i 

35 

Set 

40 F^=S, + tG, 

F, = aD, + a(1+p) (1-a) X^^ + a(1-a) (1-a-ap) X^2 + a(l-a-ap) (1-a)^ X,_3 + a(l-a-ap) (1-a)^X 
Var (F,) = a^{a^ + (1+p)^ (1-a)^ + a(1-a-ap)^(1-a)^/(2-a)} 

45 

Estimate variance of forecast by 



50 ^ 



Estimate variance of forecast error t)y: 

55 

Var (F^^i - D^i) = {l+a^ + (l+p)^ (1-a)% (a(1-a-ap)2{1-a)^y(2-a)l 
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* - Winters method • - 

This conventiona) model is appropriate when the depended (forecastable) variable Is assumed to fluctuate around 
a linear trend line modulated by seasonality factors. I.e. 

X, = (^+G,)c, + e^ 

)i the Initial deseasonaOzed level, G the trend or slope component and q the multiplicative seasonality factor. Assume 
that the season consists of N periods. I.e. c, = for all t. The seasonality factors are normalized such that: 

Winters* method uses three smoothing factors, a. p and y as follows: 
Inputs: 

Time Series Data to be forecasted (for example POS- or shipment). 
Season length N. 
Smoothing factors, a. p and y. 

Outputs 

Future forecasts and their variarv;es. 
Al^rithm Steps 

Step 1 : (Initialization). Use first two seasons (periods - 2H+^ , -2H*2 0) to initialize values: 

la: Calculate sample means for two separate seasons of data. 

lb: Define Gq = (V2 - V1)/N as the initial slope estimate. 

1c: Set Sq = V2 + (N-1)y2, as an estimate of the value of the series at time t=0. 

Id: Compute Initial estimates of seasonal fectors; tfiese are obtained by dividing each of the initial observations 
by the corresponcfing point on the line connecting and V2. i.e. compute: 

C j = Xj/I{Vi - (M4-1)/2h)G J. i = -2ri|.1.....0 

le: Average seasonal factors as computed for the two seasons 

2 ' ° 2 

If: Normalize seasonal factors: 
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-10*1 

i-O 

5 

Step 2: Update recursively: 

St = a(X/Cj^) + (1-a)(X,.i+G,.i) 

10 

G,-p[S,-S,.i] + (1-p)G,., 
C, = Y(D/S,) + (1-Y)Ct.N 
15 Step 3: Create forward forecast in period t for period 

l"i.t^.=(S, + xG,)C^.N 

Regression based forecasting models 

20 

In this conventional model, it is assumed that the forecastable variable X is determined by m(:^1) exogenously 
measurak)le (forecastatile) variables 2f^^\ Z^\...Z^) as follows: 

X. = a + b, Z'^', + b2 Z« b^zC") , + s, 

25 

where {eJ are indeperxJent with mean zero arxl variance o^. 
Inputs 

30 Time series for {XJ and all explanatory variables Z^\....2^'")) For exanrtple market share, total market value, 
installed base, GNP, etc. 

Time series data to be forecasted (for example POS a shipment) 

Outputs 

35 

Estimates of coefficients a, b^, b2.-..b^ as well as o^. 

Forecast for future value of X, on the basis of estimated future values of Z^^\ Z^^ Z^^\ 

Algorithm Steps 

40 

Use of starxiard multiple regression method. 

Autoreg'essive / Moving average rrxxiel (Box Jenkins) 

45 In this category of mode^ it is assumed that the forecastable variable pct) exhibits an autocorrelated structure. The 
most general model of this type is speckled as an AF^A (p^q) 
model, i.a 

= P 1 + P 2 ^1-2 +" PpXt-p + ^1 

Where 

55 with {uj independent with mean zero and variance o^. 
Inputs 

Tone series data to be forecasted (tor example POS or shipnrtent). 
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Outputs 

Identification of optimal values of p and q. 

estimates of coeffidents p ^ Pp and r i.- -*Tq as well as a^. 

5 Forecast of future value. 

Algorithmic Steps 

Standard Box-Jenkins Algorittim and Process with forecasted value computed as follows: 

10 



15 

Seasonality factors estimation 
Otsjective 

20 

To estimate for each time bucket (quarter, month, week) Hs percentage of the yearly volume. 
Input 

25 Historic data t>y aggregated at the same level as the seasonality 
POS 

Shipment 

Total market volume, etc. 
30 Output 

Seasonality factors for each time bucket. 
Algorithmic Steps 

35 

Compute for each time bucket the proportion of the yearly volume it represents. 
Forecast Accuracy Models 

40 To estimate the accuracy of the various types of forecasts. Measures of forecast accuracy are used in various cor>- 
texts. 

It is a proxy measure for the variarK:e of the forecast when this one carviot directly t>e computed. Forecast variance 
is used in several inventory and safety stock cateulations. 

Forecast error measures can also be used to identified those products and customers for which demand patterns 
45 are particularty unstable arxi thus require special attention. 

Forecast error cateulation 

Objective 

50 

To compute forecast erra for the forecast prodiK^edn periods ahead. 
Input 

55 Actual Sales 

n periods ahead Sales Forecast (BU, TP. 
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Output 

Average Absolute Error as of percentage 
Mean Square Error 
5 Table of forecast accuracy as function of n 

Al^HTtbmic Steps 

Conrpute the percentage difference between the forecasted and actual sales. 
10 Corrpute average absolute error and mean square forecast error. 

Exception report generation 

Objective 

IS 

Togeneratethe fist cf the products or customers for which the forecast error was greater that ^ 
cast error threshold. 

Input 

20 

Average Absolute Error 
Mean Square Error 
Forecast error threshold 

25 Algorithmic Steps 

Rank Ost In decreasing order of Average Absolute Error or Mean Square Error 

Output 

30 

Exception list ordered list of products for which the forecast error was higher than the threshold 

Models Specific to the Manufacturing Environnrtent 

35 The particular aspects of the manufacturing environnrtent call for specific nxxlels in the area of forecasting and plan- 
ning. In particular a forecast approach that spedficaDy nxxlels the ordering pattern of retailers based on tfieir replen- 
ishment policy and le^el of sale to the final consumer is considered. Approaches for the nrxxieling of sales pronxstions 
are ato proposed. 

40 Expert based model for Bottono-up forecast 

This discussion descrfoes an algorithm to conrputebottonrKp forecasts design in the best avad- 

able point estimates of sales as well as a characterization of the degree of urYcertainty surrounding these estimate s . 
The system develops forecasts for each account each model and each tinr>e-period. These are subsequently aggre- 

45 gated over all accounts. 

The analysis starts with a characterization of the account's anticipated sales pattern for a given nrxxiel. Hs order to 
the manufacturer are obtained as derivatives of this sales pattern, assuming that a specific systematic refdenishnoent 
policy is followed by the account The prevalence of a systernaticreplenishm (in the absence of capacity prob- 

lems) is an important assumption but one which we have verified in our analyst of real retailer's behavorior. 

50 Prerious investigations of point-of-sales data have estaU^hed that the accounts' sales pattern is much more pre- 
dictable and regular than the nonnal order stream. It is therefore appropriate to start the forecasting process with a 
characterization of the accounfs sales pattenri Moreover, we envision that t^»6 inputs 

retaaer in cooperation with or as a result of monthly meetings with account representatives (buyers, logstics manag- 
ers). The account representatives are deariy wore fanruliar with their sates pattern than the resulting order stream to 
55 their supplier; their estimates for future orders are dearly driven by their anticipation of future sales. 

The need to characterize the urx:ertainty of tfte marufacturer's nrxxiel sales stems primarBy from the fact that this 
characterization is to be used as the foundation for inventory planning, i.e. the determination of the so-called l-fine or 
lower bounds for the l-fine required to assure customer service levels wNch are compatS)le with the manufacturer's 
Quick Response targets. 
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To assess rranimum inventory requirenrtents one needs to characterize cumulative sales over time rather than or in 
addition to sales per month. Extrenrte care needs to be exercised in aggregating sales over consecutive months since 
these are highly corr^ed. Thus, a straighttonward convolution of orders in consecutive months would lead to serious 
underestimates of the variability of cumulative orders and her>ce to the determination of inappropriately low safety 

5 stocks (minimum inventory levels), exposing the manufacturer to undesirable frequent stoctouls. These would result in 
inappropriate a^tomer sendee, loss of market share and last but not least, a continuatk>n of the vicious cyde prevent- 
ing the manufacturer from establishing reliable forecasts in the first place. 

Our approach provides an exact characterization of the statistical distrftxjtion of cumulative sales based on a given 
characterizatkxi of the undertying sales pattern. 

10 The cakxJus used to characterize the distra>utions of account orders and aggregate orders Is t>ased on simple but 
rigorous probability calculus. 

The system is intuitive and fully transparent to all users. Below we give a brief outline of the inputs required by the 
system and the user interfaces which we envision developing to provide the user with various types of backgrourvi infor- 
mation to facOitate the task of specifying forecast inputs. 

15 The calculus used to derive all order and aggregate order distributions is explained. 

Required inputs; user interfaces 

The user will be responsft)le for entering forecasts for specific account/hnodel comt>tnations under his/her respon- 
20 sa)irrty. For any giv^ account/model conrtt)inat)on, foreca^ are to be provided for the next 12 months on a rolling hori- 
zon basts. The user will be confronted with a main menu permitting a choice between: (I) whettier to provide estimates 
of the accounts' sales (II) or orders (12); and (II) whether to provide estimates of monthly total sales (orders) (111) or to 
provide separate estimates (112) for 

25 (a) regular sales activities, and 
(b) Promotiorial activities 

We will stronc^y encourage LAMs to opt for 

30 (1) providing estimates for sales, and 

(2) providing separate estimates for regular and pronx>tional sates 

If option (12) is chosen, the calculations described below will be circumvented arxl by default orders in consecutive 
months will be treated as independent. (This may result in important distortions as explained in the introduction but is 
35 unavoidable under this option; the user cannot be expected to estimate the intertemporal con-elation pattern. It is con- 
ceivable that an "average" correlation factor may be inferred from historical orders.) 

All accounts managed by the three LAMs whom we have interviewed follow or would like to follow a simple replen- 
ishment policy of the folkiwing type: (a) the nrvxiel's inventory position is reviewed periodically (e.g. once a weeK once 
in two weeks, once a month); arvf (b) at review epochs the account places an order to irx^^ease the modefs inventory 
40 position to a target level of a given number of weeks of future expected demarxfe (ag. 6 weeks, 8 weeks) unless the 
current inventory position is already above this target level in whk;h case no order is placed. 

The formulae befow are based on this type of replenishnient policy which is characterized k>y two parameters only 
(the review period and the target order-up to level in weeks). This poCcy structure is easy to use and eff k:ient from rme 
tfian one point-of-view. However, it wfll t>e easy to make appropriate modifications should it become apparent that other 
45 types of replenishment policies are used by some accounts. 

Inputs 

Sf = sales in period t (rarxfom variat)le) 
50 m= Est 

W = number of periods of future demarxis to whrch the inventory position is to be increased every time an order is 
placed. 

The distribution of St is obtained by fitting an appropr^e distribution to the three point infomrtation provided tiy the user. 
55 We fit a shifted Binomial distohutionrL^ 

Si"™" = minimum sales for period t 
Si"^ = maxinujm sales for period t 
Sx"^ =most likely sales volume for period t 
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Left St = s, - S,"**" and assume is BirK)mial:(n.p) with n = S^"*^ - Sx"^ - 

(np + (1 -Pjj+I = s 1 e.g. p = (s , -s 1 .1)/h 
([x] - denotes the largest integer smaller than or equal to x) 
Outputs 

Ot = order in period t 



Ob= cumulative orders in periods 1 t 

IPt = inventory position at end of period t after placing an order (= inventory on hand -i- outstanding orders) 
Tt= target order-up to level at end of week 




The following recursive relationships hold (assuming backlogging; the equations are easily adjusted for the co^ of lost 
sales) 

IP, = IP,.i-s,+[Tt-IPM+sJ* (1) 

Ot=n",-iPM+s,]* (2) 

Ot=OM+rr,-IPM+Sj* (3) 

We assume here that the St - variables are independerrt of each other. 
Calculating IP, and o, - distritxitions 

The distr^on of the IP, - varices can be computed recursivety. Observe the IPt.i and s, are independent of each 
other. 

Prob[IP, = TJ IP^i = 0 = Pr[s, ^ I - T J (4) 

Hence, 

Prob[IPt=Tj = 



(5) 



For r > Tj, Prob[IPt = r |IPm = 0 = Prob[Si = I - r] 
Hence. 



48 



EP0770 967A2 

Prob[IPt = 1'] = 



52 Projb[JPt.i3<rt=i] •Projb[5t=i-i'] 

i=oiix(Tc-l.i 



70 (6) 



75 



20 



25 



Problo, = 0 1 IP = n = Prob[s, ^ I - T,] (7) 



Prob[Ot » 0] = 



52 ProJb[St.il-rt] Projb[JLj.i=l] 



(8) 

30 Calculating Cumulative Order Dstributians 

The distrftxjtions of cunfuilative orders. I.e. the (Oj) - distribution can be computed recursively as well but only by com- 
puting the joint cfistribution of 0^^ and 1P|.^ : 



35 



Case 1 Let k'>k: 

PrtO, = k*andlP,=TJO,,i =k.lP,.i = 0 = Prfs, = k'-k + l -TJ (9a) 
Prt0/= and IP, = r 1 0,.^ = k, IP^^ = G = 0 (9b) 

40 foralir=iftT, 
Case2k'=k: 

Pr[Ot = k and IP^ = 1' | 0^,1 - k and IP^.i = 11 = 

|pr[St=l-l'] if Tt^l'^l 
\ 0, otherwise 
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(10) 



50 



55 



Thus 

PrIO, = k'andIPj = TJ = Pr[0^.i =KIP^i =1]. 
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j=i' 

(11) 



JO 

PrtO^.i =k'and IP,.^ =11. 

PrtSt = l-r] (12) 

IS 

Past Promotions Effects Estimation 
Ot^ective 

20 To assess the total impact on sales of past promotions. 

Promotions perturb the regular pattern of sales and various types of promotional activities influence the sales vol- 
umes according to rather different patterns. The objective of the model Is therefore to assess the pattern of the inpact 
of the pronation over time. 

25 Irputs 

Times series of sales. 
Time period of the promotion. 
Class of the promotion. 
30 Type of the promotion. 

Intensity of the promotion. 

Outputs 

35 Overall Impact of the promotion 
Profile of the impact over time. 

Algorithmic Steps 

40 The nrxxiel Is based on the use of time series models. Rrst. an analysis is applied to a "censored" time series of 
sales volumes, in which all promotion (and after promotion) periods have been efiminated. One of several basic time 
series models is applied to identify trerxl factors, seasonality indices and/br auto correlation structures.These basictime 
series models include exponential smoothing (weighted) moving averages, Winters* rruxiel, Box-%Jenkins models. The 
following Modified Winters' Procedure uses the demand (POS or shipment) data to remove seasonality and trerxi 

45 effects. 

Select time series model for estimation of demand for nort-promotion perioc^ 
Initial Estimation of Level (including trend) at each Historical Period. 

Calculate the mcving average of seasons^ with each season having period P. If P is an even number, take the average 
of two consecutive moving averages to let the estimat e centered on the time period. 

50 

Estimate Seasonal Factors. 

Divide the actual demand by the centered moving average to obtain the estimate seasonal factor. Dampen the ran- 
dom effects tsy taking averages for sim3ar periods in cfifferent years. Then, normalize the estin^ seasonal factors ttiat 
55 totals to P Using the norrnalized Seconal factors remove the seasonafityeffecte 

Estimate Level and Trend Terms. 

Using the reg-ession equation algorithm speoTied in the MDA 1 34 rrxxiule. find the regression parameters tor level 
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and trend coefficients to fit the regressicn line: Using the regression coeffidents remove the trend effects from the -"^^ ^ 
demand data. 

After an appropriate time series model has been selected for all non-promotion periods, interpolate base-line sales vol- 
umes in the pronrxTtion periods which would have arisen tn the absence of the special promotion activities. 
5 Calculate the ratios of the actiffll sales voluntes during the promotion periods and the calculated "base line" values, for 
each promotion period separately. This d^ines the impact curve of the promotion. 

Aggregate the impact curves pertairvng to differ^ proniotion periods of a given type into a sin^e curve using standard 
curve fitting techniques. 

The resulting impact factors for each of the periods t>elonging to and following after a promotion interval can now 
10 be used in future forecasting efforts. 

Future Promotion Impact Estimation 

Objective 

15 

To estimate the impact of a future promotion 
Inputs 

20 Time period of the pronfKition 
Class of the pronation 
Type of the promotion 
Intensity of the promotion 

25 Outputs 

Estimated overall impact of the promotion 
Estimated profile of the impact over time. 

30 Algorithmic Steps 

Search pronfx>tion calendar for past pronrtotions with similar characteristics. 
Assess irrpact of the planned promotion based on computed effect of similar pa^ promotions. 
Identify generic proffle of prorrxTtion irrpact correspondng to the planned promotion. 
35 Compute estinrated profile of tfie planned pronKilion tiy combining estimated total irrpact and generic profile. 

Analyze Promotion Effects 

This analysis includes the following three types of promotional activities: price prorrxytions, where the item price is 
40 reduced by a given percentage for a limited period of time (e.g. 1 -2 weeks); proniotions via feature advertisements: and 
promotions via special store displays. 

TTie characterization of the irrpact of pronrrotional activities is to be used as the basis of the s tati s ti cal forecasting 
procedures in the Forecasting module of our DSS 10. It will also be invoked as guiding information in the bottonup 
faecasting procedure. 

45 The sales promotfon activities perturb the regular sales pattem in the commerda) setting. Conespondingly, special 
events such as scheduled exercise in the defense application will also significantfy change the usage of parts. There- 
fore, tfre models developed tor arralyzing the effects of sales promotions will also be appBcaUe in understancfing the 
effects of tire special events in the deferise siting. In the folkiwirrg section vve enptc^ a 
of explanation, wfule the irrodels are equally appfk:ab(e to tx>th the defense and commercial applications. 

50 It is both intuitive and extensively substantiated ty several statistical studies in the conventional marketing literature 
(see e.g.. Bla1tt>erg and Naslin (1993)) ttrat tfre various types of prorrrational activities influence the sales volumes 
according to rather different patterns. Price pronrrotions typically result in a significant increase in the sales vdunrre dur- 
ing the course of the pronation period The increase in ttre sales volume is due to: 

55 a. consuniersinaeasing their nornrial purchase quaritities to take advantage of the ten^^ 

b. considers making a purcf^se during the pronrxition period who ottrervv^ 
in time; 

c. consumers being enticed into a purchase who otfrenmsewouU have opted for a (Afferent brand a wfw 
would not be in the market for tttis itenrr. 



51 



EP0770 967A2 



10 



45 



50 



55 



Only factor (c) results in a significant tong term tnaease of tfie sales volume. The first two factors (a) and (b). on the 
other hand, cause an increase of the sales volume during tfie promotion period, txit the increased volume Is partially or 
completely compensated for by a decline in sales after the pronrKition period. 

Figure 31 cfisplays a typical pattern for the percentage increases over tin^e. resulting from a price promotion. As 
mentioned, the percentage increase is positive during the promoticm period: the magnitude of the impact first inaeases 
and then decreases. The promotion perkxJ may be followed by an interval of time with a negative impact; the magnitude 
of the decline first inaeases and then decreases. See Lewandowski (1985) for more details. 

The impact of promotions via feature advertisemarits or special in-store displays may exhbit a similar pattern (as 
in figure 18); altemaliv^ the impact of these types of promotions may be confined to the promotion period itself. 

Regression Models 



Our menu of regression equations consists of variants of the following basic equation used in Blattberg and Wis- 
niewski (1988) arxJ with minor changes in Wittink et al. (1987). 
15 Let: 

Sj, = Weekly retail sales for item i at time t 
Rj) = The regular (shelf) price of itm i at time t 

Pj^ = The observed price (actually paid by the consumer) for item i at time t 
20 Dj, = Thedeal dfecount for item i at time t ((Rrt-Pii)/Rit). 

CPjt = The price of a competitive item j at time t with j not equal to i. 

Xjt = A dummy variable which equals 1 if a (fisplay is run for item i at time t, 

Yjt = A dummy variable which equate 1 if a feature ad is run for item i at time t 

Ljt = A variable representing deal decay, equaling lq-1 with j being the time since the beginning of the deal and 
25 0<k<1, 

The basic regression model is: 

30 

All of the data required for this model are available in our data sources. The only possible exceptions are the CPjt -num- 
bers which reflect prices charged for Items provided by competing vendors. We foresee that the latter may not t>e avail- 
able in some commercial supply chain settings. If so, the item ^^C^CPit is efiminated from equation (1). On the other 
hand, a trend and seasonality factors (expressed ag. via incficator variables) may be added to equation (1). For exam- 
35 pie, if tfie year is divided into four dtetinct seasons, add the variables Z^l if period t is part of season I (1=1 ,K, 3) (along 
with a trend term) to the right hand side of (1): 

Sff-exp{ai+pYi^if+T22'2,+T3^3^a2fftf+a3D^+a4Xj^+a5Y^+a6L^} (2) 

40 The log-linear formulation in equations (1) and (2) has been shmn to provide significantly better precfictions than the 
simple linear formulatbn. The spectficatk)n in the conventional Blattk>erg and Wteniewski model implicttly assumes that 
the impact of a promotion is restricted to the promotion period itself and that the magnitude of the impact exponentially 
declines over tima To alk)w for a general pattern of impacts as in figure 30, we are considering the following variant Let 
denote an upper bound on the number of periods over which a price promotion exercises a significant impact, arxi let 



U|j =1 if period t arises I periods after tfie beginning of the last pronxytion period. 
M,K,u 



(3) 



The coefficients of the above regression equations will be d^ermined by using the generic regression routine specified 
elsewhere herein. 
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Time-Series Modeb --^ • ^-^^ - • - - - -j^.. -.^.-^ • - 

An attemative approach to analyze retaOer promotions s based on the use of time series models. Rrst an analysts 
is applied to a "cerrsored*' time series of sales volumes, in which aD promotion (and after pronrtotion) periods have been 
^iminated. One of several basic tin^e series models is applied to identify trend factors, seasonality indices and/or auto 
condition structures. These basic tinrte series models include exponential smoothing (weighted) moving averages. Win- 
ters' model. Box-Oenkins models. The following Modified Winters' Procedure uses the demand (POS or shipment) data 
to remove seasonality arx^ trend effects. 

Step 1 . tnrtiat Estimation of Level Ctnduding trend) at each Historical Period. 

Calculate the moving average of seasons, with each season having period P If P is an even number, take the aver- 
age of two consecutive moving averages to let the estimate centered on the time period. 
Step 2. Estimate Seasonal Factors. 

Divide the actual demand by the centered nraving average to obtain tiie estimate seasonal factor. Dampen the ran- 
dom effects by taking averages for simitar periods in different years. Then, normafize the estimate seasonal factors 
that totab to P Using the normafized seasonal factors renrxTve the seasonality effects from tiie demand data. 
Step 3. Estimate Level and Trend Terms. 

Using the regression equation algoritfim specified elsewhere herein, find ttie regression parameters for level and 
trervJ coefficients to fit tiie regression fine. Using the regression coefficients remove the trend effects from the 
demand data. 

After an appropriate time series nrvxiel has been selected for aO non-pronrKition periods, one can interpolate the so- 
cafled base-line sales volumes in the pronrxrtion periods which would have arisen in the absence of the special promo- 
tion activities. By calculating the ratios of the actual sales volumes during the promotion periods and the calculated 
"'base line" values, one con^ructs an impact-curve as in figure 31 for each promotion period separately. The irrpact 
ounces pertaining to different promotion periocte of a given type can next be aggregated into a single curve using stand- 
ard curve fitting techniques, see figure 32. The resulting inpact factors for each of the periocfe t>elonging to and folk>w- 
ing after a pronrxstion interval can now be used in future forecasting efforts, as guided by our Forecasting Module. This 
approach follows that of Abraham and Lodbh (1 992) who have successfully adopted the methodologies in their eariier 
PROMOTER system to analyze retailer promotions. The PROMOTER model has four primary steps: (1) adjustment of 
the data for trerxj. seasonality, (2) elimination of data points influenced by promotion. (3) extrapolation of data points not 
influ^iced by pronrxstion into pronxstion period, and (4) computation of promotion effect as the difference t>etween ttiis 
baseline arxi actual sales. 
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MODEL 


WHERE USED 


Statistical forecasting models: 

• movincr av@T*dcr& 

• trend 

• smoothing models 

• Holt Winters model 

• Winter's method 

• Regression based 
forecasting 

• Autoregressive / 
Moving average models 


Demand Characterization 

Top-down Forecast 
VMR 


Expert based forecasting model: 


Bottom-up Forecast 


Seasonality factors estimation 


Demand Characterization 

Top-dovm Forecast 

PSI 

VMR 


Poif^f^afit acfc\iiraf?v i^utines • 

• Forecast error 
calculation 

• Exception report 
generation 


Bottom— UD Po recast 
Top-down Forecast 
PSI 
VMR 


Past promotions impact 
estimation model: 

• Regression model 

• Time series model 


Sales Promotion Analysis 
Bottom-up Forecast 
Top-down Forecast 


Future promotion impact 
estimation model 


Sales Promotion Analysis 
Bottom-up Forecast 
Top-down Forecast 



Table 10 
Usage of SFP Models 



Modete Specific to Repair Environment 
Definitions 

Equipment consists of modules tfiat are composed of reparak)le items, and repairakile items are made of compo- 
nents. 

Requirement: failure of an equipment 

Consolidation policy: the policy of replacing the defective reparatsle item of a failed module with a good reparable item 
of an already defective module arxi reinstalling Into tfie equipment 

Defective ratio: ratio of numt>er of defective reparable item to the total number of reparatrie items in a nxxJule. 
Target level: maximum defective ratio acceptatsle before a module can be sent back from tf^ location to the 

repair depot The target level is one of tfie tvvoparam^ers of the consoBdation policy. 

Raw requirements (pre-consolidation requirements): total requirements generated by all equipment at the equipment 
location 

Ck>nsolidated requirements (post-consolidation requirements): requirements for equipment after consolidation policy is 
applied to raw equipment requirements (number of modules sent to repair depot for repair from tfie equ^>ment location) 
Raw Requirements Estimation (for Bottom-up estimation) 

Objective 

To estimate raw requirements for all equipment located at a particular equipment location t>ased on the planned 
activity (usage) schedules of the equpment 
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Equipment (ocated at the equipment location. 

Activrty schedules for all the equipnrtent at the equipment location such as: 

equipment i^jgrade/ifnairrtenance schedules (preventive and breakdown maintenance schedules) 
activities (i.e., operation time, number of setups, cumulative operation time) 
planned activity schedules for all equipment at the equipment location 

Output 

Estimations of the raw requirements for each equipmerrt at the equipment location 
Algorithmic steps 

Establish relationships between raw requirements and activities of the equipment based on analysis of graphs, etc. 
Analyze the effects of activities on requirenYents using regression or time-series models 

Estimate raw requirements for each equipment given the equipmenfs planned activity schedule by the models used 
atxiva 

Consolidated Requirements Estiniation (for Bottonvup estimation) 
Objective 

To estimate consolidated requirements lor all equpment located at an equipment location based on the estimated 
raw requirements 

Input 

Estimated raw requirements for each equipment at the equipment location and the time of requirement 

Batching parameter for the t>atching policy of the equipment location 

Consolidation policy (target level and the search rule) 

Inventory positions at the equipment location for nrxxiutes and reparable items 

Performance measures: stock level, service level (availability of equipment), repair cost associated with repair at 
equipment locations and the repair depot 

Output 

Estimates of consolidated requirements for all equipment at an equipment location 
Values of performance measures 

Algorithmic steps 

Search under consolidation po6cy 
Identify repairable items to be sent to repair depot under batching policy of the equipnrtent location 

Consolidation Policy 

Aconsolidatk)n policy consists of two elements: a search rule for selectir^ the defective repairatsle item to be cort- 
soTtdated. and a target let^el, that is ttie maximum defective ratio acceptable before a module can t>e sent back from the 
equipment kx:ation to tf^ repair depot. 

Given a newly failed module of type I with a defective reparat)le item of type j, the consolidation policy defines which 
reparable item should be chosen out of which module to perform the consofidation. The chosen repairable item should 
already be part of a module with at least one defective reparable item but containing a good component of type j. The 
search rule select the reparable item for oonsofidation among all such defective modules. The foUowing search rules are 
considered: 

Carry out the search for defective modules of type I only. Sort the defective modules of type I in decreasing order 
ofthedefectiveratioarxJstartirigfromthetopof the Dst select the first module tfral has a good cc^^ init if one 
exists. If not. sort all the other defective modules in deaeasing order of tfie defective ratio and starting from the top of 
the fist, select ttte first nxxluletttathasagoodreparableitemjinit if one ex^ Knot, (consolidation cann^ 
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replace the fafled module l-with a gcxxi one, rf one ts available at the equipment location. If not, equipment becomes • 
unavailatsle untO either a consolidation or a replacem^ can be mada 

Determine all module types for which stocks of good items at the equipment location are below a threshold value. 
Sort the defective modules of aD such types in decreasing order of the defective ratio and starting from the top of the 

5 list, select the first module that has a good reparable item if one exists. If not. sort all the other defective modules in 
decreasing order of the defective ratio and starting from the top of the list, select the first module that has a good repa- 
rable item j. if one exists. If not (consolidation cannot take place) replace the failed module of type I with a good module 
of type I. if a good one is available at the equipment location. If not. the equ^ent becomes unavailable until either a 
consolidation or a replacement can t>e made. 

10 Sort the defective modules of all types in deaeasing order of the defective ratio and starting from the top of the list, 
select ttiefirst module that has a good reparable item j in it if one exists. If not (consolidation cannot take place) replace 
the failed module of type I with a good one. if one is available at the equipment location. If not equ9>ment becomes una- 
vailable until either a consolidation or a replacemerrt can be made. 

IS Batching Policy 

The batching policy Is defined by the size of a batch. TH1, (TH1 can be equal to 1). The inventory policy is in the 
form of: count the number of d^ective nxxiules with defective ratio greater than the target level. If tiiis number \s greater 
tfian TH1, then send TH1 units of repairable items to tiie repair shop e^ wait until this condition is satisfied. 

20 

Consolidated Requirements Estimation (for Top-down estimation) 
Objective 

25 To estimate consolidated requirements for all equipment located at a particular equipment location based on his- 
torical data 

Input 

30 Time series of consolidated requirements for each equ^ment locations. 
Output 

Estimates of consolidated requirements for aD equipn^ at an equipment location 

35 

Algorithmic steps 

Use a conventional Kalman filter based algorithm and conventional statistical forecasting methods to estimate con- 
solidated requirement for the equipment 

40 

Determining a repair plan 
Objective 

45 To determine a repair plan based on aggregate repair plan, and repair constraints (resource capacities and key 
component avail^ility) 

Input 

50 Aggregate repair plan 

Available resource capacities and degree of f Iex2}aity to change resource capacities 

component availability (projected inventory positions^ supplier and lead time information, inventory replenish- 
ment polkry) 

55 Output 

Repair plan for the repair shop that is feasSsle with respect to the repair constraints (capacity and key component 
avaflability). 
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Rnished Goods Inventoiy Management (FGIM) 164 ^^--^^^ - - • — - ^ 

Scope and objective 

5 Objective: Decide where to ^ocK how much and when to replenish in (hyt>rid) made-to-stock/made-to-order envi- 
rorenent. 

Scope: Single and dual echelon. 
Features: 

Single and dual echelon Inventory models for how much and when to replenish stocking points. Cost vs. service trade 
10 offs to determine where to stock. 
Deployment 

Models specific to manufacturing envimnment 
Overview 

IS 

Objectives 

This module contains a collection of finished goods* inventory models enabling the selection and evaluation of 
inventory policies. The module returns an I- arxl P- line extended to a given horizon (of T periods) beyond the cunent 
20 period. At th^ stage, all of the models represent settings where any given item is distrftxjted to the customers from a 
single location. 

Input 

25 Forecasts of mean demands per item, per period (S' Bne); standard deviations of demands per period per item {& 
line); mean production lead times for each period per item (L line); standard deviations of lead times for each period, 
per item (x* line). 

Output 

30 

Inventory (I) line 
Production (P*) line 
Inventory strategies 

Models are classified as follc3ws: Ml. Models with Non-Lumpy Demand; and Mil. Models with Lximpy Demand. Lump/ 
35 demands refers to settings where demarxis are sporadic or experience extreme variak>ility. The demand process for a 

given item will k>e classified as lurrpy if the percentage of zero demand periods or the coefficient of variation of the 

demands is akxive pre-specif ied critical levels. 

Within the category Ml we next dfferentiate between: MI.1 Models managing inverrtories or on an item-by-item 

basis; and M1.2 Multi-item modete with joint capacity constraints. 
40 The choice between these two categories depencte on whettier or not important interdependerK:ies prevail between 

the items (in the fomi of joint capacity constraints or joint cost structures). Within each of the sutxHtegories MI.1 and 

MI.2. (Afferent models can t>e selected based on the extent to which policy parameters are to be pre-specified by the 

user or computed based on an appropriate tradeoff between cost and service measures. 

45 Ml Inventory Models for Non-Lumpy Demand 

MI.1 Models for Independent Items .... 

As mentioned at)ove, in this category inventories are managed on an rtem-by-item basis. Different models need to 
50 be invoked dependent tpon the extent to which policy paranrieters are to be specified by the user. Alternatively, the 
models to be used can be determined endogerxxisly based on an appropriate tradeoff analysis or optimization of van- 
ous cost and service measures. 

Ml.1.1 User-Spedfied Base-Stock Policies 

55 

Otijective 

In this model, the user specifies an orderHJf>to or base-stock level as a given nunriber of we^ Based 
on this inventory policy, the model projects out an r and P line for a scenario in wfhich the forecasted nrtean demands 
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are realized.* - - . , . . . .:r .r.^,^^-...- 

Ackfitional Inputs 

The desired base-stock level for each period 

nx = number of periods of future forecasted denfiancte in which the inventory posHion is to be increased at the begin- 
ning of period t if belcw 

Algorithm 

Step 1 : Compute bi = St + S^.^ +...+ Sni- (If n, is specified as a fractional value, bt equals: 
bt = St + Sn.i+...+ SLntj + (n, - ["tJ) ^nri) 
Step 2: Project I' and P' lina L^: 

lb = inventory position (inventory level plus outstancfing orders) before ordering at beginning of period 1 . 
Pt = productbn volune ordered at k>egirtning of period t. 

Set Pi = bi - Iq; project recursively for t = 1 .....7-1 : 

I^i = max(bt. It) + P,-St 
Pt^i = nrax (bj^i - lt+1 : 0) 

Step 3: Evaluation of various service arxi cost nneasures. 

a) ag., expected average inventory level. 

b) probat^lrty of stock-out 

c) f 01 rate or percentage of demands satisfied from stocK 

d) number of setups, 

e) average backlog sizes. 

Mt.1.2 MIN-MAX Policies Based on Optimization of Aggregate Cost Measures 
Objective 

In this nrxxiel, a policy ts computed which nninimizes the expected value of the aggregate of alt relevant cost com- 
ponents. I.e. 1) setup costs; 2) inventory canying costs: and 3) t>acklogging costs. The model is appropriate in setting 
where stock-outs are fuOy backk>gged and where the inventory carrying and bacMogging costs are proportional with the 
inventory levels arxJ backlog sizes. 

Additional inputs: 

Holding cost rates per item per period (h' line) 
BacMogging cost rate per items per period (p* line) 
Variable production cost rate per item per period (c* line) 

Algorithm 

Step 1 : Load S' (Sales). & (Standard deviation). V (Lead times). V (Standard deviations of lead times). IC (setup 
costs), h* (Holding cost rates), p* (b^ogging cost rates), c' (variable production cost rates); 
Step 2: Fit appropriate demand d^'bution to S*. & Ones. 
Fit appropriate lead time disbtxjtions to L* and t* fines. 

Step 3: Solve for time-phased optimal (s.Q) policy. Such a poScy has for each period t = 1.....T. two critical levels St 
and Qt such that whenever beginning inventory position l|<St an order is placed for (SffOi - It) units. Parameters (St. 
Qt) are computed from the following recursion. 
Let: 

V,(l) = expected minimum costs in periods t t+1,....T given that period t starts with an inventory position of I 
units. 
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10 



Gfy) = expected (inventory carrying and backfogging) costs associated with period t (This function uses the -"' 
lead time and demand distrSxjtions computed in Step 2 as well as the h' and p' lines.) 
Dt = demand in period t 

Solve: 



Note: the user is provided with the option to specify ranges for the production quantities X(, x,+i .... ^j. These ranges 
may reflect capacity limits per item, or f lexbility limits in view of prior determined P' and r lines. The ranges will be 
used to restrict the choice of x . 
Output: 
IS For all t= 1 T; 

Xt*(l) = optimal order quantity at the beginning of period t when inventory position = I. 

Step 4: Create i* and P* lines. 

20 1^ is known; set P^ = production lot initiated in period 1 equal to X^^ (I). Then project recursively for t = 1 T 

*t*i = »t + x*t(IJ-St 

25 Step 5: Evaluation of various cost and service measures, as in Step 2 of model M1.1. 
MI.1 .3 Periodic Review Models Under Servk^e Level 
Constraints 

30 

Objective 

In th^ category of models tf>e inverrtory poHcy minimizes expected setup and holding costs subject to user speci- 
fied sennce level constraints. The user may choose between the two types of conventiona) servk:e measures. 

35 

Type 1 Servk;e Constraints: 

Maximum permitted probak)ility of a stock-out during lead-time foltowing potential order at beginning of a given 
period. Let: 

40 op maximum permitted likelihood of stock-out during lead-time foIk»ving potential order at beginning of period 

t 

Type 2 Servrce Constraints: 

Minimum acceptable fill rate during lead time folkswing a potential order at beginning of period. Ril rate is defined 
45 as the percentage of demand satisfied from stock. 
Let: 

minimum acceptable f 01 rate during lead time fblkywing a potential order at t>eginning of period t. 

50 The model is based on the same assunptk)ns as MI.1 except tfiat stock-out frequencies are controlled via service 
level constraints (of Type 1 or Type 2) as opposed to escplictt stock-out or backlogging costs. 

Additional Inputs 

55 hokfing cost rates per item per period (h* fine) 

maximum permitted stock-out probat»lities per item per period (a* line), or minimum acceptable fiD rates per item 
per period (p* Bne) 
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Step 1 : Ljoad (Sales), & (standard delations). L (lead-times). K* (setup costs), h* (holdtng cost rates). C (variable 
production cost rates), a (service level type 1) or (service level type 2). (Lead-times are specified eitti^ as con- 
stants or via ranges with assodated like&hood tor each value in the range.) 
Step 2: Rt appropriate demand distribution to S', a* lines. Determine lead time demand distrft)utions. 
Let: 

LDt = lead time demand for order placed at beginning of period t If lead time demand distrbution Is chosen to 
be Nonmal (for example), then set Its mean and variance as follows: 



j-i 

i-i 



Step 3: Compute minimum Inventory positions after ordering St . via Reorder Point Algorithm, below: 

Step 4: Solve for time-phased optimal (s.Q) policy. 

Let: 

V, (I) = expected minimum costs in periods t, t+1 T given that period t starts with an inventory position of 1 

units. 

Gfy) = expected inventory carrying and backlogging costs associated vtrith period t 
Dt = demarxi in period t 

Solve: 

t = 1, . . . ,T; all I 



Output: 

forallt = 1 T; 

x*t (I) = optimal order quantity at the beginning of period t. when inventory position = I. 
^lote: the i^er s prcvided with the option to specify rariges for the product 

may reflect capacity limits per item, or flexilxlity Emits in view of prior determined P and T lines. The ranges will be 
used to restrict the choice of X In (2). 
Step 4: Create T and P lines. 

h B known; s^ = production lot initiated in period 1 equal to x*^ (0. Then project recursively for t = 1 .....T 
»t.i = »t + x*,(IJ-S, 

Step 5: Evaluation of various cost and service measures, as in Step 2 of model M1.1. 
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• Ml^ Multi-item (Capacitated Periodic Re^ew Models vvith Service Level Cor^strairrts . rsn^. - -c^ • • 

Objective 

This category of models plans simultaneously for a complete family of items incorporating various joint capacity 
constraints. The model plans production quantities on the basis of estimated mean demands; however, nvnimum inven- 
tory levels are specified to satisfy user specified service constraints (of Type 1 or Type 2. see Ml. 1 .3, aboste). The P' arvJ 
r line are in this case determined by the solution of an LP-model. The user specifies whether minimum inv&rtory levels 
are to be determined on the basis of Type 1 or Type 2 constraints. In addition, the user chooses aoKing a numt>er of 
possible objective functions (performance measures) to select among feasible plans. 

LP fomtulation 

Model: 

LP formulation for I products (or product group) K resources (Key Component and/or Lines) sets and T periods 
Input 

Sjt = Demand for product i at period t 

Sh = Minimum anxHint of product i at the end of period t 

Ijo = Initial inventory of product i at the beginning of the planning horizon 

ami = Units of resource m. anrK>ng resources in set Sk, requred per unit production/repair of product i 

Crnt = Units of resource m which becomes available at period t (In case resource m is a component, 0^0 is the 

amount of it available at the beginning of the horizon under consideration.) 

Decision Variables: 

Pit = Units of product i to produce in period t 

Xmit = Units of product i to produce in period t using resource m in Si^ 

lit = Inventory of product i at the &nd of period t LP (A) Optimize: 

0V1 , 0V2, 0V3 or OV4 specified below: 

subject to 



Iit-i+Pit-Sit=Iit for i = 1,2,..., I and t = 1,2,...,T (1) 

in sjcXndt=Pit for k = 1,2, . . . ,K, i=l,2, . - .,1 and 

t = 1,2, ... ,T (2) 

E-oto c^^i a^x^»<=E3.o totC«. for each key component m and 

t: = 1,2. .,T (2.1) 

j:.c^^Xoii^<=Cp^ for each line resource m and 

t = 1,2, ... ,T (2.2) 

li^asu for i=l,2,...,I and t = 1,2,...,T (3) 

Xn^tiO for m in Sjt, k=l,2,...,K, i=l,2,...,I and 

t = 1,2 T (4) 



Constraints: 

calculate the inventory levels, 
(2.1) and (2.2) ensure that consumption does not exceed resource ava^abitity. 
ensure inventory is no less than pre-spedfied levels and ensure that productionA-epair is non-negative. 
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Output: 



Feas&aity of LP 

5 K yes, a production plan : Pj^ for i = 1 ,2,... J and t = 1 ,2 T the corresponding Inventory levels : l^t for i = 1 ,2 1 and 

t - 1 ,2 T and remaining resources : slacks in (2.1) and (2.2). 

If no. display sources of infeasd)ilrty : surpluses in (2.1) and (2.2). 

OV1 : Maximize maximum slack in resource constraints (2.1) and (2.2) 
10 0V2: (Balance Workload). 
minL[ami WCmtJ 

OV3: Minimize variat)le production and holding costs 
minL[CHPit + hrty 

OV4: Minimize maximum inventory in weeks 
15 nan maxj, [ yS^ ] 

Algorithm 

Step 1 : Load S* (sales), & (starviard deviations). L' (lead times), h' (holding cost rates), c* (variable production cost 
rates), V (standard deviations of lead times); resource utOization matrix [Bj^i capacity levels [CmJ. 
Step 2: Determine lead time distrSxitions ID^, as in Step 2 of Ml. 1.3. 

Step 3: Compute rrwiimiHn inventory positions after ordering s^ ."\&r via Reorder Point Algorithm. 
Step 4: Solve atxjve LP. 
Step 5: Identical to Step 5 of model Mil .1 . 

II. Inventory Models for Lumpy Demand 

Apply to lumpy demand. The lumpiness of demand is measured as proposed herein. 

30 M 3.1 Maximum Demand during Period 'n' Policy 

Objective 

This policy is suitat>le for km cost slow moving items with lunrtpy denrtand. 

35 

Inputs 

S' line, cover period n. 

40 Outputs 

MAX level, inventory target. 
Frames using these models include 
PSI Planning Frame 160 (CF8) 
45 VMR Frame 250 (CF19 and CF20) 

Algorithm 

Step 1. Usemetf>od 1 to categorize iLonpy demand 
50 Step 2. Determine *n'; a worst case scenario woukJ be to set 'n* as the replen^ment lead-time. 

Step 3. Determine the maximum demand duririg penod *n' and set it as the inventory target. MAX. 

Step 4. Compute r line: 

lj,_i+Xjt<J|t = Ijt for i = 1,2.... J and t = 1,2....T 

55 M 3.2 Expected DeSkit MIN-MAX 

Objective 

This policy is suitable in cases where there are fairly expensive items that have lumpy demand. 
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-Inputs - - ^ ' - 

S' line 

Outputs 

Max level, inventory target 
Frame i^ng ttie model includes 
PSI Planning Frame 160 

Algorithm 

Step 1. Use method 2 to categorize lumpy demand 

Step 2. D^ine expected deficrt due to lumpiness as average amount that the quantity on hand is likely to fall before 
a replenishment order is placed. 

Step 3. Approximate the expected d^icrt (average period sales) as one-half of the beginning and encfing quantity 
on hand between quantity-on-hand record updates. 

Step 4. Set ROP as safety stock plus demand during the le^time and expected deficit. 

Step 5. Set the MAX let/el as the ROP quantity plus the order quantity less the expected deficit. 

Step 6. When the inventory level reaches the reorder point the difference between the targeted quantity MAX and 

the quantity-or>-hand is ordered. 

Compute the T line: 

^^+^■<^^t = Ijt *w j = 1 .2 J and t = 1 ^,...T 



MODEL 


WHERE USED 


Inventory models for independent 
items with non- lumpy demand: 

• User specified base-stock 
policies 

• Min-mcuc policies based on 
optimization of aggregate 
cost measures 

• Periodic review models 
under service level 
constraints 


PSI Plauining 
VMR 


Inventory models for multi-item with 
non- lumpy demand: 

• Capacitated periodic review 

model with service level 

constraints 


PSI Planning 


Inventory models for lumpy demand 

• Mcucimum demand during 
period *n' policy 

• Expected deficit min-max 
policy 


PSI PlcUining 



Table 11 
Usage of FGIM Models 



Models specific to repair environment 
Deterrnning CSI levels 
Objective 

To determine CSI level for each module typa 
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Input * - ^ . . • 

repair shop repair time estimates 

consolidated requirements for equipment for ttie previous pehocte 
Output 

CSI levete fa each repairat)le item type 
Algorithm step 

For each repairable item, set CSI level to CSI^^* calculate the corresponding performance measures. Based on 
values of the performance measures and the estimated consolidated requirements, change the CSI level and repeat 

Performance measures that can be considered for determining the CSI level for each repairable item are the total 
cost of repair (setup cost + repair cost), arvi the fill rate (service level) at the repair shopi 

CSI level for each repairable item nrust be greater than or equal to the value of CSImin. which is simply the sum of 
the requirements during repair time and a safety stock. CSImin ^ EIrequirements over all equipment locations during 
repair time of one unit] -i- safety stock where safety stock is a user defined parameter, based on past requirements. 

Determining aggregate repair resource requirements 

Objective 

This process includes the objectives: (i)- to estimate number of cortsolidated requirements for equipment triggering 
repair at the repair shop; (iO- Siven (i). to estimate nunrt>er of repairable items requiring repair at the repair shop: and 
(iii). given (ii). to estimate aggregate repair requirements at the repair shop 

Input 

CSI levels 

consolidation policy target level 

Types and numt)ers of repairable items in each equipment 
BOM for each repairable item (to go to the component level) 
Rnal estimations of consolidated requirements for the equip>ment 

Final estimated repairable item requirements con^esponding to the consolidated requirenr^ents for equipment 
Repair data for each repairable item (operation sequence and repair time e^mates for each operation) 

Output 

Aggregate repair requirements at the repair shop 
Algorithmic steps 

Estimate number of consolidated requirements for equipn>ent triggering repair at the repair shop 
Estimate number of repairable items requiring repair at the repair shop 
Estimate aggregate repair requirements at the repair shop 
Generation of a feasible aggregate repair plan 

Ot)jective 

To generate an aggregate repair plan t>ased on aggregate repair requirements, and repair constraints (resource 
capacities and component availabOity). 

Input 

Aggregate repair requirements 

Available resource capacities and degree of flexi)ility to cf^nge resource capacities 

Key component availat>aity (projected inventory positions, sufsplier and lead time information, inventory replenish- 
n^ policy) 
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BOM for each repairable rtem famity (to go to the component level) 
Output 

Aggregate repair plan for the repair shop that is feasble with respect to the repair constraints (capacity and key 
component avail^ilrty) 

Algorithmic Steps: 

Check if aggregate repair requirements are feasB^le with respect to capadty constraints of the resources 
If not change capacity levels of flexible resources. If still infeasS)le. point out infeasibility arvi go back and move aggre- 
gate repair requirements forward or backward in time 

Determine key component requirements and time of requirement from aggregate repair requirentents 

Check if aggregate repair requirements are feasible with respect to key component availat>ility constraints 

If not point out infeasbility in tenns of componerrt availability. Charge k^ compon^ availability (if it can be changed) 

equipment based on the purchasing policies for the comportents. If still infeasible. go t>ack and nxive aggregate repair 

requirements fonvard or t>ackw»rd in time until a feasS)le repair plan is generated 

Aggregate Production Planning (APP) 162 

The Aggregation Production Module 162 focuses on its PSI Frame 160 application. The folkTwing two capacity 
checking models are identified and developed to support the Model Engine 20 requirements in the PSI Rame 160. 

Objective and Scope 

Objective: Facilitate the master production scheduling process. 
Scope: Rntshed goods production in some aggregate view. 

Features: Rough-cut capacity checking for finished goods; Major components (feeder plants) represented in con- 
straints; and At}ility to identify violated constraints. 

Capacity Checking Models 

In the Capacity Checking models, the problem of checking whether there is enough resources to satisfy require- 
ments is formulated as Linear Programming Problems. These models are applicable to both the manufacturing and 
repairing environment in tfie PSI frame. The capacity checking models are presented in manufacturing terms these 
models also apply to the repair environment and are used in the context of the Requirement-Supply Reconciliation 
frame to assess the feasibility of a repair plan. 

Sales and safety stock sanity check 

Objective 

Check whether there Is a feasible procfaiction plan to satisfy given sales arxl safety stock requirements. 
Ir^ 

I = The number of products to be considered. 

K = The number of resources (production lines and key components) sets. 

S|( = The set of resources. 

T = The planning horizon. 

Sit = Demarxi for product I at period t 

ISSit = Safety stock of product I at the end of period t 

ljo= Initial inventory of product I at the beginrung of the planning horizon. 

a^^j = Units of resource m. among resources in sei S^. requred per unit production of product 1. 

Cmt = Units of resource m wtvch beo^nes avalatsle at period i (In case resource m is a k^ component. Cmo >s the 

amount of it available at the t>eginning of the horizon urxier consideration.) 
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%t t/^ Output— ' • T .t t->r%T 

FeasibOity of LP 

5 tfyes. 

a production plan: 

PHfori=1^.....landt=1^ T 

the con-esponding inventory levels: 

litfori = 1^ landt = 1.2,....T 

70 arxi remaining resources (slacks in constraints (3) and (4)): 

2^ to t Cms - ^ to t ^ i amPte ^ ©ach key conrponent m and t = 1 .2 T and c^t - 2: j a^^n for each production line 

mandt = 1,2 T 

If no. (fisplay sources of infeasbiiity (surpluses in constraint (3) and (4)): 

tot ^iafiiPW-^ tot Cms for each key cornponentm and t= 1^ T and Lian^Xmit-Cnrtfof each production line 

15 mandt = 1.2.....T 

Lir^ear Progranmng Forntjlation 

Dedsion Variables: 

20 

Pit= Units of product I to produce at period t 

Xmit = Units of product I to produce at period t using resource m in set S|(, 
dn =Denriand for product I during the period t 
l(t = Inventory of product I at the erxJ of period t 

25 

Objective functions: 

Minirnze maximum production line utilization (smooth production line utilization): 
Minimize z 

30 sut>ject to E I amptfnit'Cmt <= z for each line resource m arxl t = 1 .2.....T 

Minimize maximum inventory level: 

Minimize z subject to lit <= z fa i = 1,2 1 and t= 1.2....,T. 

Minimize total inventory level: 

Minimize Ej Et 'it 
35 Minimize total inventory cost 

Minimize 2^ E| [h^ Ih*+ Ph lit") 

subject to Irt = li,+- Irt'. Ij,*>= 0 and lit" >=0 for I = 1 ^,...,1 and t = 1 ,2 T 

where hit = cost per unit holding and 

40 Pit = cost per unit backlog of product I at the end of period t 

Constraints 

Inventory balance formula 

45 

In-i+Pit^lit for i = 1 ,2.... J and t = 1,2,.„,T 
Resource allocation 

^ m in sk Xmit =Ph tor k= 1 .2,.... K and t = 1^,.... T 
Key component availability 
^ tot ^iami^nB<=^ tot Cms tor each key componertm and t=1Z---T^ 
Production line capacity 

^ i afniXmit<=Cnrt tor each production fine m and t = 1 ,2,...,T 
Safety stock requirement 

lrt>=ISSH fa i= 1 ,2 1 and t := 1 ^ T 

55 Non-negative resource allocation 

Xmit>=0 fa m in Sk. k= 1,2 K, I = 1,2,...,l and t = 1,2.....T. 

Capacity Checking Model 

CCM1 : Lto selected objective furK:tion sutsject to the above constraints. 
Frames using ths model include PSI planning (CF13). VMR. (CF 20) 
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The LP formulation, with minor changes, is also applicable to a repair environment where reparable items'con'e-'^'' ^ 
spend to products, repair requrements for reparable items correspond to demands for products. arxJ broken reparable 
items awaiting repair at the repair shop correspond to key components. 

For the repair environment, k^ component availabi&ty constraint (the fourth constraint) should be modified as in 
5 the following to represent broken reparat)le item availatxlrty at the repair shop : 
4) Broken reparable item availability: 

2W)tDt ^ m ^is<= 2^ tot Cfe for each repairable item 1 and t 1.2 T. 

Objective functions and the other constraints in a repair environment will t>e similar to those of a production envi- 
ronment, which are given atxTva The LP model for the repair environment will either produce a capacity feasible aggre- 
10 gate repair plan that sat^es the repair requirements generated by reparable item failures or display sources of 
infeasibility. 

Production requirement fe^biiity check 
IS Objective 

Check whether a given production plan is feasible with respect to aggregate production capacity and key compo- 
r^ertt availabifity. 

20 Input 

1 = The number of products to be cornered. 

K = The number of resources (production lines and k^ compon^its) sets. 
Sk = The set of resources. 
25 T = The planning horizon. 

PiP Units of product i to produce at period t 

a^j = Units of resource m, among resources in set S|(, required per unit production of product I. 

Crnt = Units of resource m which becomes available at period t. (In case resource m is a key oonrponent. Cmo is the 

amount of it available at the beginning of the horizon urxJer consideration.) 

30 

Output 

Feasftjility of LP 

35 If yes, display remaining resources (slacks in constraints (3) arxi (4)): 

^^tot^W-^^tot^iamP^feforeachkeycomponert mandt= 1.2.....TandCm^ line 
mandt=1,2.....T. 

If no. cfisplay sources of infeasibility (surpluses in con^airrt (3) and (4)): 

^tot ^iamPVnis-^tot Cms for each key componertm and t = 1.2.....T and £ line 
40 mandt= 1.2,....T. 

Linear Programming Formulation 

Decision Variables 

45 

Xfrtit = (^its of product 1 to produce at period t using resource m in set S^. 
Capacity Checking Model 
50 CCM2 : Objective function 1) subject to constraints 2). 3), 4) and 6). 
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MODEL 


WHERE USED 


Capacity checking models: 

Sales and safety stock sanity check 

Production requirement feasibility 
check 


PS I Planning 
VMR 



Table 12 
Usage of APP Models 



Vendor Managed Replenishment (VMR) 252 
Overview 

This section describes the specifications of the various models used in the VMR nxxiutes. The description is 
divided into three main categories: (1) Inventory Requirements Setting Models. (2) Strategic Models, and (3) Opera- 
tional Models. The notation for these models is introduced as necessary throughout this section. 

The models developed in this section are based on prior results in the professional literature as well as from other 
sources. 

Scope and objective 

Objective: Analyze contractual agreements with customers; and Decide on what to ship, in what cfuantities and 
when. 

Scope: Selected products for selected custonrters. 
Features: 

Evaluate policy parameters such as bounds on customer inventories, target service level and delivery frequencies. Sta- 
tistical forecast of retailers* sates (i e, forecast of sales of PCEC's customers to their customers). Determine shipment 
requirements and delivery schedules. 
Inventory Positioning: The Multi-Item, Two Echelon Model 

Overview 

This section presents two models; the first model describes an algorithm for the calculaticn of required echelon 
inventories. (Echelon inventory = inventory in transit from the plant to the DC + inventory on hand at the DC + inventory 
in transit from the EX) to the stores + inventory on hand at the stores.) The secorxJ mode) estimates the expected level 
of service provided at a certain D.C. given a delivery quantity. Two important parameters used in both models are the 
expected value and standard deviation of the lead-time demand. These models compute the stock-out probabflity of 
toda/s delivery on the day of its arrival to the stores. This is based on the approximation ^ 
prior research on the Mutti-ltem. Two-Echelon production/inventory systems Setting Inv^itory Requirement Model (R) 

Objective 

This module corrputes the required echelon inventory levels (R* line) at the beginning of each review period over 
the whole planning horizon. Clearly, these requirements depend on the delivery frequency used (the requirements 
increase as the delivery becomes less frequent). Thus, the required inventory labels (R' line) are calculated separately 
for each one of the pre-spedfied delivery frequerxses. 

Input 

Network structure 

Demand forecast (means. starKlard (teviations ard cfeperston factor). 
Required service levels Qn terms of stock-out probability). 
Set of possS^le delivery frequencies. 
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- Lead-times from each plant to every DC it replenishes, and the average lead-times from every DC to the stores it 
suppGes. 

Planning horizon specifications 

5 Output 

Required inventory lines (R' lines). 

Notation 

10 

to - t>eginning period of the planning horizon (assuming that today* is the beginning of period number 1). 
T - the length of the planning horizon. 

R*f(i j) - required inventory level, of product j at DC I, at the beginning of period t when delivery frequency f is 
applied. 

IS Oq - reqidred service level for product j at DC I. 

^ ij - mean demand tor product j at DC I durir^g period t 

o^y - standard deviation of the demand for product j at DC I during period t. 

b\ - demand cfispersion rate for product j at DC t. The dispersion rate is defined as follows: 

" restores (i) 

and is assumed to be constant over time, stores (I) denotes the set of stores replenished by DC I. Note that we do 
25 not require the data o^yr which represents standard deviation of demands at individual stores. The parameters b\js 

can be calculated (or even roughly estimated) by an observation of a set of historical stores* data. 

Ljj - Lead-time from the plant that produces product j to DC I. 
- Average lead-time from DC I. to its stores, for product j. 

Q - Set of 'quarters' into which the planning horizon is split Each quarter is a continuous time interval consisting of 
30 one or more periods. 

Qq, Qq! - Quarter number q arxl the nuniber of periods in it (note that ). 

F - The set of all possible delivery frequencies. Each delivery frequency f is specified as the minin^l number of peri- 
ods between two consecutive delivery periods. The values f must be integral (for norvintegral values, redefine the 
t>ase period, e.g. half a week instead of a week). 
35 |i\j(m). o'q(m) - The mean and standard deviation of the demarxJ for product j at all stores supplied t»y DC I, over 
periods t until t+Ljj++m (m^ is a parameter of these functk>ns). The term ti-l^j++m represents the expected time at 
whrch a delivery shipped from the plant at period Um (next possible delivery time), arrives to the stores. 

Algorithm Steps 

40 

For all product-DC couples (i,D 
For all frequencies f in F 
tinrre :=0 

For all 'quarters' q in Q 
45 F6rallperioctet= 1 toOq! 
time := time + 1 

// confute the time to next feasit)le delivery period, 
t_del. // 

tjdel :=f-[(t + f-1 )nrKXlf] 
50 time_to_DC := tjdel + Lfj 

time_to_stores := time_to_DC + ly 
compute the values 
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(R.2) 



and 

10 

(R.3) 



l^time 



for a part of a period use the following interpolation method: Let X be the period nurTt)er and Iet0<a<1bethe fraction 
of that period. Then. 
20 (R.4) mean = a 

(R.5) std = 



25 



Use (R.5) if the demand in this part of the period is assumed to be independent of the demand during the rest of the 
period. Another way to calculate the standard deviation can be. for instance, 



The inventory requirement for period time is now computed via 

35 (R.6) 

{i.j) =(1^^" ( t__dei ) ^-0-1 ( 1 -o^^) d'^y^ { t_del ) 

End For (t) 
End For (q) 
End For (f) 
End For (i,D 

Estimate Stock-out Probability for a Given Replenishment 
Quantity: Model (0R1): 



Objective 

For a given replenishment quantity of proc^ j, delivered from plant p(j) to DC I. this model estimates the expected 
50 projected stock-out probability. The stock-out probatMfity is defined as the probabilrty of shortage in at least one of the 
stores replenished by the DC The word "prelected" relers to lead-time periods later, when goods are expected to reach 
the stores. 



Notation 

55 

In addition to the notation darned uptothis pdnt we define: 

DEUV - delivery siza 
date -date of delivery. 
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arr - (expectecQ anival date of goods to stores ' - 

)^„date . echelon inventory level of product j In EX) I. at (period) time data 

Algonthm Steps 

Use formula (R^), wrtfi t__del=1 . to calculate the expected demand over the lead-time, 



date 



a?5 

10 

(1). Similarly calculate the standard deviation of this demand, 



(1), via formula (R.3) (again. t>y setting t_del=1). 

The projected stock-out prot>at»Iity can be approximated t^y: 



20 



(OR.l) 



25 



30 



In certain situations the user may be interested In knowing the projected service levels for periods further than arr. Such 
interest may arise wtien no deliveries are planned for subsequent (number of) period(s). To evaluate the projected 
stock-out probak)ility at period arr+K when no deliveries are to be made during the follovknng k periocte (i.e. dat&i-l , .... 
date<4^), use the formula: 

(OR. 2) 



35 



date i 



Strategic Mod^: VMR Contract Setup © 
40 Objective 

This nrKxiule consists of a set of nxxiels tailored to support replenishment planning by integrating: (1) servk^e level 
rec^iremenls; (2) limits on customers* inventory investments; (3) transportation costs; arxi (4) delivery frequency. 

45 Input 

BekTw is the input which is oomnion to all of the models described in this partku . 
Network Structure. 
Demand Forecast 

50 Lead-times from each Plant to each DC and (an average) from each DC to its Stores. 

Planning Horizon Specifk;ations 

Current Inventory Positions. 

Transportation Cost Structure and Trucks Volumes. 

Products* Vbtun>es (for Transportation Cost Cakxdations). 
55 Computing The Optimal Delivery Frequencies: Model (CI) 

Objective 

Th^ model computes delivery frequencies from each plant to tiie DC it replenishes such as to minimize total trans- 
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portation costs. The delivery frequencies are set such that given requirements on service levels are satisfied and such 
that constraints on average Inventories are not violated. 

Input: 

Inventory Requirements (R* Line, see Model R). 

Set of Possble DeTivery Frequencies. 

Required Service le^eAs (in Terms of Stock-out Probabilities). 

Umits on Maximal Inventory Investments (in terms of Weeks of Demand), 

Output 

Delivery Frequencies. 
Estimated Level of Service, 
Estimated Transportation Costs, 
Estimated Inventory Leve^ 

Notation 

We use the same notation as in Model R (except for the notation for delivery frequencies) plus the following: 
Indices 

1- DC index 

j - product (module) index 

p - plarrt Irxjex 

f - delivery frequency IrxJex 

s - index of line segment of fransportation cost function (the cost structure is appraximated by a piece-wise linear 

function) 

t - time index 

q - quarter index 0 

Sets 

I - s^ of all DCs 
J - set of all products 
P - set of all plants 

F - set of possible delivery frequerKses 

J' - all products sold to DC 1. 

Jp - all products produced in plant p. 

Transportation cost paran>eters (fr>r d^iveries from plant p to DC i) 

volip - total volume of a single truck 

Cjp - cost of full truck load (FTL) 

f ixp - fixed cost of less ttian full truck bad (LTL) 

f i)^ - (rigW) end point of the Srth line segmenl (i e.. i^p^sr^ . fesj ) of the LTL cost function, 
rateip^ - transportation cost rate for volumes in segment s (i.e., in between and Xjp a), for LTL shipments. 
Vj - volume of product] (for cost calcination purpose) - upper limit on the average number of weeks of inventory in 
DC i in quarter q. 

Decision variables 

X'ij - echelon inventory of product j at DC I (including outstarxiing orders) in the beginning of period t. 
S'y - delivery quantity of product j to DC I in period t 

F^pf - an indicator set to 1 if in quarter q a delivery frequency f is folfowed for the replenishment of DC I by plant p. 
Othenv^ it is set to zero. 

NFT*jp - number of full^truck-toad sent to DC I from plant pduring period t 

LTL*ip - volume of LTL (zero if none) shipment sent to DC I from ptent p during period t 
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Y*ip^ - total volume of LTL shipmert that falls into Gne segment (cost rate category) number s. Note that 
Z*ip,8 - an indicator set to 1 if the LTL shipment size is larger than Xjp ; i.e., segment s is partially a entirely cov- 
ered. Note that Z*ip,s is always less or equal to 2*^^^ . 

5 Algorithm Steps 

The follcwing Mixed-Integer Linear Programming problem is solved: 
Problem (CI): 



10 



q^O txQ^ p€P [ s 



S.T. 

IS Initialize inventory positions: 
(C1.1) 



V 1 1 



20 System dynamics: (expected) beginning DC echelon inventory - (expected) beginning Inventory of 1^ period + deliv- 
ery quantity to the DC during the last period - expected demand in the last period: 
(CI .2) 

Xj,*=Xg'''+Sg'-'.|l/' ij.t>1 

25 

Beginning (expected) inventory level needs to satisfy the requirement constraint, for the relevant frequency level: 
(CI. 3) 

Only one frequency is chosen for each triple pC. product and quarter): 

35 

(CI. 4) 

40 

Average echelon inventory (across all products) should not exceed a given level. This level is given in terrns of weeks 
of inventory. Note that we sut>tract one half since X is the beginnir^ inventory level (while we are interested in average 
over the period, i.e.. Xiiy2): 

45 

(CI. 5) 



50 

Upper bound on the numt)er of full truck loads (FTL): 
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(CI. 6) 

NFT, 



10 

Lower bound on the nuniber of FTLs: 
(CI. 7) 

15 



20 

Defiveries not send by the FTLs are sent by LTL 
(CI. 8) 



25 



30 

Setting the transportation cost constraints (See 4.8.1): 
(CI. 9) 



35 



40 



45 



(CI. 10) 



(CI. 11) 



7 5 > 7 
^ip» s^^xp, s*l 
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Integrality constraints 



i,p, t,s 



50 i,p,t,s 
(CI. 12) 
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(CI. 14) 

irP,q,f 

(CI. 15) 

10 NFTi^In eager s 



15 To estimate the operating parameterSp descrbed atxive as part of the output of this model, use Model (C4) (described 
later). 

Computing Maximal Average Levels of Service: Model (C2) Objective: Gven the delivery frequerK:ies arxi limits on the 
average number of weeks of (ech^on) Inventories, ths model calculates the maximal average service level that can be 
obtained. 

20 

Input 

Inventory Requirements (R' Line, see Model R) 
D^rvery Frequencies 
25 Limits on Maximal Inventory Investments On terms of Weeks of Demand) 

Output 

Estimated Level of Service 
30 Estimated Transportation Costs 
Estimated Inventory Levels 

^k>tation 

35 We the same notation as in Model CI plus the following: 

a*y - "projected" (i.e. "lead-time" periods after period t) level of service for product j in DC I at period t 
Tjp-agivensetof periods in which replenishment (from plant p to DC 0 is permitted. 
Wy - values of objective coefficients (see discussion later) 

40 

Algorithm Steps: The folk>wing problem is of interest 
Problem (C2): 

EE E E 

qiO it! cs.0gjeji 

ST 

(C2.1)(C1.1) 

50 (C2.2){C1.2) 
(C2,3) (CI. 5) 

Formula used to approximate the "projected" level of service (see Model (0R1): 
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(C2.4) 



i, j , t 



10 



No delivery can be made in periods that are not compliant wHh the given delivery frequencies 



{C2.5) 



15 



Sij^O fox all tCTj 



20 Note that Problem (C^) is separable both in I and in q. In addition, in order to deal with the non-linear constraint (C2.4) 
we approximate the Standard-Normal cumulative distrbution furKrtion (^) by a piece-wise linear function (with m seg- 
ments); for further details, see below. 

As in Model (C1). we define for the piece-wise Gnear function the parameters arxl variables (for further details, see 
below): 

25 

m - number of "segments" in the piece-wise linear function. 

- the s-th l)reakpoirrt of the piece-wise linear function (s=0.....m); i.e. the s-th segment is given by Ps-i , % ]. 
ds - the slope of the s-th segment of the piecfr^se linear function (s=1 m). 

e - the binary variables associated with this transformation. 
30 g - the continuous variable associated with this transformation. 

In the following problems we use Z^g and Y^j g with respect to 



see below. 
Problem (02)^^ : 

40 



45 S.T 

(C2M) (C1.1) only for the relevant value of i and teQq 
(C2*.2) (C1.2) only for the relevant value of i and tcQq 
(C2'.3) (C1.5) (single constraint) 
See the discussion herein for details on (C2'.4)-(C2'.8): 

50 
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(C2'.4) 

s-1 



10 j , t 

(C2' .5) 



15 



20 



30 



35 



40 



(C2' .6) 



{C2' .8) 



25 j # t , s=l, . . . ,m-l 

(C2'.7) 



j,t,S 



45 {C2'.9) (C2.5) only for the relevant value of I 
Remarks , , 

The weights Wjj should be set such that 

50 

55 .To determine the appropriate weights one should (x>nsxier the rele^ 
priorities, demand votumes, etc.) 

In case that some products have tew service levels, the problem can be resolved with the adcfition of the foQowing con- 
straint 
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(C2' .10) 



10 

where q>jj are prespedfied lower bounds on the level of service. ArKither option, which does not require the specification 
of 9q is 

(C2'.ll) 

15 
20 

j,t, 

wrthn^l. 

25 Minimizing Average DC Echelon Inventory Levels: Model (C3) 

Objective: Given the delivery frequencies and required service levels, this model conrputes the minimal average 
number of weeks of inventories at each one of the DCs in every quarter. 

Input 

30 

Inventory Requirements (R* Line, see Model R) 
Delivery Requendes 

Required Service Levels (in Terms of Stock-out Probabilities) 

35 Output 

Estimated Level of Service 
Estimated Transportation Costs 
Estimated Inventory Levete 

40 

Notation 

We use the sanne notation as in Model C2 plus the following: 

45 pO)- the plant in which product i is produced. 
q(t) - the quarter to wfiich period t belortgs. 

rVi.D- this is the inventory requirenrient as defined for hAodeIR, but with^ It now refers to tfie given 

delivery ireqjency from plant p(j) to DC I in quarter qCt). 

AVG^i - the average echelon inventory level in terms of weeks of demand (for DC I in quarter q). 

50 

Algorithm Steps 

For each DC I in I: 

55 Step 1: For each product j.j€ J*: 
Solve the follMing problem: 
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S.T 

(C3.1) (C1.1) (single constraint) 
(C3.2)(C1^) 

to Beginning Inventories must satisfy nnininial requirenients: 

(C3.3) 



20 

End For (D 
Step 2: For each q in Q 
Calculate the value 

25 

(C3.4) 



35 End For (q) End For (1) 

Computation of Operating Parameters: Model (C4) 
Objective 

40 

Given a delivery plan (i e. the values S^^, this model computes the following operating values: (1) estimated Inven- 
tory leifels. (2) estimated levels of service, and (3) estimated transportation costs. 

Input 

45 

Delivery Plan (S'^). 
Output 

50 Estimated Level of Service 

Estimated Transportation Co^ 
Estimated Inventory Levels 

Notation 

55 

P^- Set Of all plants that replenish DCL 
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1'.* -r - • 



For each DC I in I: 

Step 1: Evaluate the expected (echelon) inventory positions at the t>eginning of each period via the equations 
(C1.1). (C1.2) 

Step 2: For each quarterq in Q 

2.1 Evaluate the value AVG\ via (C3.4) 

2.2 Evaluate the expected levels of service 0 via (C2.4). 

2.3 Evaluate total transportation costs over the quarter (can be done by an external procedure) for each plant . 
End For (q) 

Check Conpatbility of a Oven Set of Constraints: Model (C5) 
Ot)jective 

This nKxJel checks whether a set of constrains (service levels, maximal echelon inventory levels and delivery fre- 
quencies) is compatible or not. 

Input 

Inventory Requirements (R* Line, see Model R) 

Set of Poss3)le Defivery Frequencies 

Required Service Levels (in Terms of Stock-out Probabilities) 

Limits on Maximal Inventory Investments (in terms of Weeks of Demand) 

Output 

Feasibility (Yes or No) 
Algorithm Steps 

For each I in I: 

Step 1 : For each plant pe P: 

Select the nrx>st frequent among the feas3)le delivery frequencies from plant p to DC I (this represent the less 
restrictive constraint). 

FcH- th^ delivery frequency, evaluate the inventory requirements R'(i.j') by using Model R. 
Cateulate the values X*^ as in Model C4. 
End For (p) 

Step 2: For each q in Q 

Evaluate the value AVG\ via (C3.4) 

Check that 



is satisfied. K not STOP! the set of constraints is incompatible. 
End For (q) 
End For (I) 

Determine Production and Delivery Schediies: Model (C6) 
Ot)iective 

This model suggests both production and defivery scheAdes which noinimizes total transportation costs and 0"- 
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plant) inventory holcfing costs.^The plan is determined under service level constraints and constraints on average inven-^ 
tones at the DC (echelon) levels. 



Input 



Inventory Requirements (R* Line, see Model R) 

Set of PDSsit)le Defivery FrequerK:ies 

Required Service Levels (in Terms of Stock-out Probabilities) 

Limits on Maximal Inventory Investments (in terms of Weeks of Demand) 



Output 



Delivery Frequencies 
Estimated Level of Service 
Estimated Transportation Costs 
Estimated Inventory Levels 
Estimated In-Plant Inventory Costs 
Proposed Production Plan 



l^otation 



We use the same notation d^ined up to this point plus the following: 
Parameters 

hj - holding cost for unit of product j (in plant pQ)), per period. 

inv^ j - inventory of product j in plant (pQ)) at the t>eginning of the planning horizon. 

M - "t>ig" nurr*>er (see (C6,5)). 



Sets 



l(D - set of all DCs that carry product j. 

Dectsfon variat>les 

PROD^j - production batch size of product j in period 1 

INV^j - inventory of product j in plant pQ) at the beginning of period t 

Algorithm Steps 

The follGMring Mixed-Integer Linear Programming problem is solved: 
Problem (C6): 




ST. 

(C6.1)(C1.1) 
(C6.2)(C1.2) 

Initialize levels of in-plant inventories: 
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(C6.3) 



1 

10 

Inventory dynamics 

beginning inventory = last period beginning inventory + production quantity in the last period * goods delivered during 
the last period: 

15 (C6,4) 



icX 



20 



25 DeGveiy can be made only if period t is consistent with the chosen delivery frequerKy: 
(C6-5) 

30 ^ijA H ^i!p\j),t\'^ 

\feF(t) / 



35 

(C6.6)(C1.4) 
See (CI .3): 

(C6.7) 

40 



45 



-^/j^E ^/ < ^ ' J ) -^ip/'- ^^0^ J^^p 



(C6.8)(C1.5) 
50 (C6.9)(C1.6) 

(C6.10)(C1.7) 

(C6.11) (CI .8) 

(C6.12)(C1.9) 

(C6.13)(C1.10) 
55 (C6-14)(C1.11) 

(C6.15)(C1.12) 

(C6.16)(C1.14) 

(C6.17)(C1.15) 

OptkxYS for Production Capacity Constraints: 



if t 
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(C6,18) 

PRODf^prod^ 

This set of oonstraints represents irxiividual limit on production quantity for each product in any period. 
(C6,19) 



This set of constraints is relevant when the different products, nnanufactured in a certain plant p, share critical capacity 
resources. Although (C6.19) represent a single constraint for each plant (in a give period t), more corrctraints can t>e 
25 easily added. Note that both in (C6.18) and in (C6.19) lower tx>unds can be introduced. 

Limits on Storage Capacity 

Similarly to (C6.18) and (C6.19). analogous sets of constraints can be constructed in order to express, for each 
30 plant: (1) limits on irxiividual storage volumes, arxJ (2) upper limits on total volume (value) of storage, respectively. 

Operational Models (OP): 

Overview 

35 

In this section we descn'be a tamily of models, analogoi^ to Modete (C1)-(C3). The models are built to assist pro- 
duction and delivery planning for the short-term horizon. The major characteristics of these models are: 
Rolling horizon planning: production and delivery plans are made frequently (even before the end of previous planning 
horizons), thus taking into advantage ifxiated information about denrands and production capacities. 
40 High level of deiaite: capacity constraints are more detailed so that the resulting plan will both be feasble and smoothly 
translated into production orders. 

FlexftMlity in setting non-delivery periods: the user allowed to specify periods in which delivery cannot be made. This 
replaces the requirement for following a certain delivery frequency. For instance, even if ttiere is a certain guideline on 
delivery frequency, it can be relaxed at any (artNtrarily chosen) period. This reflects in added f lexitHlity, which is espe- 
45 dally important in cases of unexpected, high levels of demands (i.e. when deliveries must b>e made quickly). 

The number of constrairrts (per period) is larger in tfiese models, however, the planning horizon is usually much 
shorter than tfiat of the strategic model. In adcfition. since we do not need to select certain delivery frequencies there is 
no need to incorporate the integer variables F\f, This results in a significantly faster solution tima 

50 Joint Production-Delivery Plan: Model (0P1) 

Description 

This model minimizes the total transportatfon and Gnplant) inventory holding costs (see Model C6 for more details). 

55 

Notation 



The notation here is similar to that of htodel 06 with tfie addition of the following: 
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Parameters 

req*^ - requirement for echelon inventory le^el of product j at DC I in period t. in order to maintain a certain level of 
ipKojected" level of service (see Model 0R1 for further clarification). This nrtinimaJ level depends on the delivery 
5 schedule, see Model R for explanation on how to calculate these values (very similar to the calculation of the values 
R^f(ij))- 

Xj^ - the same as xf but now without the quarter index, 

10 

cap*p(k) - the availability of resource k in plant p, in period t 

X^j(k) - the amount of resource k required for a production of unit of product j in period t 
storage p(k) - maximal total votunrteA/alue (etc.) of inventory remaining at the end of period t in plant p. 
75 p'j(k) - the volumeNalue (etc.) of unit of product] in period t 

setup'j - setup cost to initiate a production batch of product j in period t 

Sets 

20 NoDelip - set of periods in which no delivery is altowed from plant p to DC I. 

Dedston variables 

PROD^j - production batch size of product j in period L 
25 inventory of product j in plant p(j) at the beginning of period t 

SETj - an integer variable indicating whether a setup is required in period t for product j. 

Algorithm Steps 

30 The following Mixed-Integer Linear Programming problem is solved: 
(0P1): 

C€TP€P[ S \ 3^ t 

35 

ST. 

(0P1.1)(C1.1) 
(0P1.2) (CI .2) 
40 (OP1.3)(C6.3) 
(OP1.4)(C6.4) 

Deliveries can be set to zero at any period the user chooses: 
(OPl.S) 

45 

5i^=0 i,j,teNoDeli^^^j^ 



50 Echelon Inventory levels must exceed certain levels: 
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(0P1.6) 



10 

(0P1.7) (CI .5) 

(OP1.8)(C1.6) 

(OP1.9)(C1.7) 

(OP1.10)(C1.8) 
15 (0P1.11)(C1.9) 

(OP1.12)(C1.10) 

(0P1.13) (C1.11) 

(OP1.14)(C1.12) 

(OP1.15)(C1.14) 
20 (OP1.16)(C1.15) 

Production capacity constraints (see also Model (C6)): 

(0P1.17) 

p, t,k 

30 

Storage capacity constraints (see also Model (C6)): 
(0P1.18) 

p, t,k 

Introducing setup costs: 

The operational model can be extended so as to Include setup costs (and/or setup times) as follows: 
The term 

^ ^setupf'SETj 



is added to the objective function of Model (OP1). 
50 Appropriate set of cor^straints should be added as weD; for instarK^e: 
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(0P2.1) 



5 



SET, 



Veto,!) 



(0P2.2) 



10 



PROD/^'SETf 



IS 



This constraint is pertinent if product j requires a new setup in each period it is produced. (M is a large" number.) 



(OP2.3) 



20 



(with SEl^i initialized according to the production/hon-production of product] in the last period before the planning hori- 
zon). The intuitive t>ehind th^ constraint is that if a product is produced in a given period, no setup is required at the 
25 sut>sequent period. 

Maximizing Short-Term Level of Service: Model (0P2) 



The purpose of this model ^ similar to tfiat of its long-term counterpart. Model (C2). In the same spirit of that mode) 
(C2), we change Model (0P1) as follows: 

Algorithm Steps 

35 



S.T. 

(OP2.1)(OP1.1) 
(OP2.2)(OP1.2) 

45 (OP2.3)(OP1.3) 
(OP2.4)(OP1.4) 
(OP2.5)(OP1.5) 
(OP2.6)(OP1.7) 
(OP2.7) (C2 .4) 

50 (OP2.8) (C2\5) 
(OP2.9) (C2\6) 
(OP2.10)(C2\7) 
(OP2.11){C2'.8) 
(OP2.12)(OP1.5) 

55 (OP2.13)(OP1.17) 
(OP2-14)(OP1.18)^ 



Description 



30 



(0P2): 



40 
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Remarks 



Constraints (OP2.7)-(OP2.11) use the piece-wise Bnear approximation to the Standard-Nonml cumulative distribu- 
tion function (CDF), see below. 

For explanation about the coefficients W|, see Model (C2)^. 

Note tttat in this case, in contrary to Model CZ, the problem is not separable in 1. This is due to the capacity and storage 
constraints (OP2.13) and (0P2.14), respectively. 

Minimizing Average DC Echelon Inventory Levels: Model (OPS) 

Description 

This model is analogous to the long-term model, (C3). 
We modify Model (0P1) as follows: 

Algorithm Steps 

Step 1 : solve the following problem: 



ST. 

(OP3.1)(OP1.1) 

(OP3.2)(OP1.2) 

(OP3.3)(OP1.3) 

(OP3.4)(OP1.4) 

(OP3.5)(OP1.5) 

(OP3.6)(OP1.6) 

(OP3.7)(OP1.17) 

(OP3.8)(OP1.18) 

Step 2: For each DC I: 

Compute the values 



(0P3): 



ceT ieJ j^i 



AVGi = 



(OP3.9) 
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MODEL 


WHERE USED 


5 


Inventory positioning models for multi- 
item cmd two echelons: 

Setting inventory requirements 

cio I* xiiia L. o WLii. \jLjn tjx x x u y mxr a 

given replenishment quantity 


Strategic 
Planning/ 

X a ^ X unci X 

Planning 


10 


Strategic models for VMR contract setup: 
Computing maximal average service levels 


Strategic 
Pleuining 


15 


Minimizing average DC echelon inventory 
levels 




Computing optimal operating parameters 

Checking compatibility of a given set of 
constraints 




20 


L^CUCX lltXllXXl^ ^X L. CUlU UCXXVCXy 

schedule 




25 


Operational models 

Determining joint production-delivery 
plan 

Maximizing short-term service levels 


Operational 
Planning 


30 


Minimizing average DC echelon inventory 
levels 





Table 13 
Usage of VMR Models 



Conrponent Procurement Policy Development (GPPD) 230 
Objective 

Determine which procurement policy should be used for which component 
Scope 

All components In planning bill of materials. 
Features 

Heuristic to identify the procurement policy to use for each component. TTie policies considered are: Just in Time; 
50 Bulk purchase, managed via stock policy, such as (s, S); and MRP calculus implying periodic purchase orders. 

Finished Goods Distribution Network Design (FGND) 2S2 

Objective 

55 

Determine the numt>er, kx:ation arxl capacity of distrftxjtion warehouses from a given set of potential locations. 
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Scope 

Distrftxition network excluding VMR arrangennents. 
5 Features 

Use market demarvi projections to reengineer the existing distribution network. 

Gobal optimization of system-wide costs including inbound /outbound trar^portation. fixed and variable warehous- 
ing, and inventory carrying costs. 

10 

Model Engine Utilities 22 

In addition to the seven modules defined above, there \s also a g^oup of general purpose numerical routines that 
are not specific to any of the above seven nrxxiules. These routines are collected into a design element referred to as 
15 the Model Engine utilities 22, as shown in figure 35A. Examples of the Model Engine utilities 22 include generic linear 
programrnng solvers, and statistical analysis routinea 

An Approximation of the Starxlard Nk>rmal DistrSxition 

20 Functkxi 

In this section, we suggest few continuous, piece-wise linear approximations for the cumulative Standard Normal 
d^trOxjtion curve. We use the follcwing rotation throughout: 



25 (A.l) 



0 ifeo=-«<z<ei 



30 



M M 

1 I ife„_,iz<0„s+«o 



This function consists of m segments, s=1 ,...,m. Each segment s, ranges from break-point 6^-^ to break-point Bg. The 
sk)pe of segment s is denoted t)y Bq. Hence, any segment s can be written as the linear function a^+ds {% - Q^^). In our 
35 model we limit the functions to be continuoi^ (although unnecessary), thus having 



(A. 2) 



40 



E;a . ^ for s=l 
, ^ (e^-e^.i) for s^2 



Note that in order to define the piece-wise linear furv:tk)n we only require the values 6^ , s=1 ,...,m-1 and d^, s=2,...,m-1 
45 (since 9^=9^=0). 



50 



55 
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Type 

Symmetric, 
7 segments 






Remarks 


1 = -2.7, 

2 = -1.8, 

3 = -0.9, 

4 = 0.9, 
s = 1.8. 
6 = 2.7 


2= 0.039923, 
3= 0.164589 
4- 0.351044, 
5= 0.164589 
6= 0.039923 


Enables to reach 
reasonable level of 
accuracy oyer all 
argument's values. 


Symmetric, 
5 segments 


1 = -2.7, 

2 = -1.4, 

= 1.4, 
, = 2.7 


2= 0.057692, 
3= 0.660714 
0^^ 0 . 057692 


Less accurate then 
the 7 segments, but 
requires less binary 
decision varicibles. 


Asymmetric, 
7 segments 


1 = -2.5, 

2 = -1.1, 

3 = 1.1, 

4 = 1.7, 

5 = 2.15, 

6 = 2.9 


2= 0.096904, 
3= 0.331213, 
4= 0.151834, 
5=* 0.063973 
6= 0.021037 


Reaches good accuracy 
levels for the 
highest cumulative 
values . 



Table 14 



Linear Programming (MILP) 

25 Corrsicler an LP/MILP which minimizes a Ginear) function of the decision variables X=P(i....,Xm.-*Xm) and their 
piece-wise linear functions ..... Fm(Xm). M ^ N. That is. an objective function of the type 

(B.l) 

30 „ 



35 with ail di>0. Similariy to the variat)les .....Xm,...^ , the functions pcj can appear in the (linear) constraints without 
any imitation; i.e. tt>e constraints are of the typ>e 

(B.2) 

40 H M 



45 For simplicity, but without loss of generality, we assume M=1 . Alsa for darity, we rename the variable X^ = T . We thus 
descrit>e a technique that transforms the function F(T) into a riew decision variable; say H, such that the relationship 
hisFCT) is maintained for any solution obtained tff solving ttte new MILP. . . , . 

Algorithm Steps 

50 

Let the function F:^*->!^ be as follows: 



55 



90 



EP077O967 A2 



(B.3) 



M 



F consists of m segments; segment s is given by [r^i . ]. We now introduce the following 2m decision variables: 

Ys - Is a continuous variable Q^e!^t/C) that represents the part of segment s "covered" T . s=1 m ; that is, 

(B.4) 

/5=max{min{T^.T}-T;n.i.O} 

Is - Is a Binary variable (ls€ {0,1,2....}) that indicates wh^er ) that indicates whether T covers any positive part of 
segment s; that is, 

(B.5) 



i' 



0 if r>T.., 

otherwise 



To modify the current LP/MII_P we do follow the steps below: Replace each F(T) by the term 
{B.6) 



FIT) -Efis-x,.,*X:Y,-r, 

S"0 



Add the fbllcwing cor^traints: 

Yg (s=1 m) are the split of T into the segments. 

Hence. 

(B.7) 



1b maintain (B.5), 
(B.8) 



Other constraints: 
(B.9) 



(B.10) 
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^^{o.^]\ s=^,K.m 

Mean 

5 This algorithm computes the statisticaJ sample mean of a given time series for a given period of time. 

The input for the routine is the time series . and time periods that the mean is computed over. The output is the uribiased 
sample mean quantity 



15 



Standard Deviation 

20 

The algorithm computes the statistical sanple sta r xiard deviation of a given time series for a given period of tima 



25 



The input for the routine is the time series X. and time periods n that the standard deviation is computed over. 
The output is the unbiased sample standard deviation quantity a^. 

30 

Moving Average 

The algorithm computes the moving averages for a given time series for a given period of time with specified aver- 
aging periods. 

35 



Xj^{iO=A for k=l,K,n-K+l, 



40 

The input for the routine is tiie time series X. time periods n that the movirtg average is computed ever. arxJ the nrxTving 
average period length K. The output is the movirtg average quantity 



Seasonality Factors and Trend 

50 

Seasonality Factors 

The algorithm computes the seasonality factors for a given tinte series for The inputforthe 

routine is the time series, and time periocte that the moving average is computed ever (at least two seasonal cycles). 
55 The output is the seasonality factors. 

Trend 

The algorithm conrputes the trend information for a given time series for a given period of tima The input for the 
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routine is the time series, and time periods that the trend 'is computed ever. The output is the tr^ value of the time . ^. 

series. 

There are several cfifferent methods to cafculate the seasonality factors and the trend in a time series. The most 
popular ones include Winter's conventional linear arxi seasonal exponential smoothing, and (multiplicative) decompo- 
5 srtion method developed by the US. Census Bureau, and its variant X-1 1 method). 

Correlation Coefficient 

This algorithm computes the correlation coeffictent for a given pair of time series with property defined time periods 
10 (th^e might be certain shifts in time periods in the two time series). 

U,-x)2(r,-T)2 

1 t*x 



20 The input for the routine ^ tiie pair of two time series X and X and corresponcfing time periocte n used to compute the 
correlation coefficient for the two time series. The output is the correlation coefficient r(X.Y). 

Curve Interpolation 

25 This conventional algorithm det^mines a curve with desirable shape to link a set of given points on a 2-dimensional 
space. The input for the routine is the set of given points, and the desired curve shape. The output is the curve that sat- 
isfies the required conditions. 

Weighted Sum of Two Time Series 

30 

The algorithm confutes the weighted sum of two time series. 

35 The input for the routine is the two time series X and Y the weight factors a and p and the given time periods n. The 
output the weighted sum time series 



Coefficient of Variation 

45 Ihis algorithm computes the coelftdent of variation for a given time series using unbiased statistical mean and 
standard deviation. 



50 



The input for the routine ts the time series X and the given time periods n. The output is tfte coefficient of variation for 
the time series Cx- 

55 Qoodness-of-Fit (Measure of Accuracy) 

This algorithm confutes the goodness-oMit (nrteasure of accuracy) for a given pair of time series: one s the origi- 
nal time series and the other is the simulated one. The input for the routine is the pair of two time series, and corre- 
sponding time periods i^ed to compute the goodness-of-fit for the two time series. The output ts tfie goodness-of-fit 
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' (one measure of accuracy) for a given simulated method. The measure of accuracy can take one off the following fomns 
(^sume that X=Xt)i" is the original time series, F=(Ft)i" e the forecast time series and ej = X,-Fj are the error terms): 
Mean Error: 



i 

i-1 



Mean Absolute Deviation: 

10 

IS Mean Squared Enor: 



MSE 



20 

Standard Deviation of Errors: 



25 



^ n 



n 



Percentage Error: 

30 X -F 

PEf.=—^ — ^100 



Mean Percentage Error: 

35 

40 Mean Absolute Percentage Error: 



45 



Regression Equation 

50 

This conventional algorithm conpules the coeffictents off a regression equation for a given set of time series. We 
will choose a standard corrputationat routine to calculate these coefffidenis The input to this routine is the set off time 
series. The output wfll be the calculated coeffficierTts off the regression eqi^oa 

55 Supply Chain Frame Manager 24 

Ov^ew 

A Frame 16 is designed to integrate User Interfaces, models, analyst routines and data in order to address a set 
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of related decision issuesrThe Supply GhairrFrame Manager 24 constitutes the backbone of the DSS 10 through which ^ -^^ - - - 
the User Interfaces, the models in the modules and the data are connected. The SL|)pty Frame Chain Manager 24 fadl- 
itates the integration of the dient side of the system, with which the user interacts, with the server side of the system 
where the modules arxi the DSS Datat>ase 1 2 reside 

5 The Supply Chain Frame Manager 24 is responsble for two types of integration: System Integration and Functional 
Integration. The System Integrator 310 (see figure 34) is responsible to Interpret the cGenfs request, dispatch the 
rec^est to the appropriate servers and to coordinate the corrputation load and data access. The Fmctional Integrator 
312 provides the functionary assodated with overall supply chain Instead of individual frame. These functionalities 
Indude Supply Chain Configuration. Domain Management, user access or privflege administration arxl performance 

10 nrxjnitoring or simulation. 

System Integration 

The Rame Manager 24 is responsa)le ft)r the dienl-server integration in the DSS 10. In this aspect the Frame Man- 

75 ager 24 provides the linkage between the Frames 16. Model Engine 20 and the DSS Database 12; responds to the 
dedsbn requests from the cGent programs by accessing the models and data; and maintains the "component objects" 
(ag.. otsject linking and embedding OLE objects) that share functionality between different Frames 16. B^ed on the 
decision requests, the Frame Manager 24 launches the appropriate ok>ject with the appropriate data, manages the 
requests from different dients for the same service and executes the appropriate server programs. The server pro- 

20 grams execute the request, and return the results to the Frame Manager 24. The Fifame Manager 24 will interpret and 
return the results to the Frames 1 6. 

The high level architectu-e of the System Integrator 310 is shown in figure 35 and indudes a Client Manager 320. 
a Request Interpreter 322 arvJ a S^er Manager 324. 

The architectural design of the Frame Manager 24 r^ects maximum f Iex9>i]fty arxJ robustness of the DSS 10. The 

25 dient side indudes all the Lteer Interface 18 of each Dedsion Stqsport Frame, such as D&nand Managemerrt. Supply 
Management etc. The Frame Manager 24 includes two major pieces, the Functional Integrator 312 and the System 
Integrator 310. Two other components runrting on the server side are Decision Support System Datat>a&e (DSS Data- 
base 12) and the Mathematical Model Engines 20. The dient program 314 talks to the Frame Manager 24. The Frame 
Manager 24 is the one responsible to call individual conponents running on the server to fulfill the dient's request. 

30 For exanrple. a user is working on a PSI frame to devetop production plan for a specific scenario. After deciding sev- 
eral key parameters, the user wants to check on the production capacity. The user makes this request from the User 
Interface 18 (drck a button or select a menu item). The request is sent to the Frame Manager 24. The Frame Manager 
24 interprets the request and determines that it needs to move the Capacity Checking Model to get the answer. (In a 
more general case, it may need to call nrK>re than one Model to accomplish the \cb.) Then the Frame Manager 24 deter- 

35 mines whe^er a model Server already running an6 on whk^ machine it is running. If there is one. it sends tfie capacity 
checking request atong with the necessary data, to that server. If there is no Server running at that time, the Frame 
Manager 24 will start up one on a selected machine and serxte the request thera Sophistk;ated dispatching polides 
can t>e implemented at the Frame Manager 24 to balance the bad or improve response times. After the Model Engine 
20 finishes the job, it returns the result to the Frame Manager 24. The Frame Manager 24 then synthesizes the result 

40 and retun^ the result to the dient 

When the Frame Manager 24 calls the Model Engine 20. it has two options in terms of passing the data. Rrst, it 
can obtain the data from the DSS Database 1 2 and p^ it to the Model Engine 20. This will be done when the arrKXjnt 
of data that need to be sent to the Model Engine 20 is not very larga The advantage of this approach is that the partic- 
ular Model Engine 20 does not require the capability to access DSS Database 12. But the data has to travel from DSS 

45 Database 12 to Franrie Manager 24 and then from Frarne Manager 24 to the Model Engine 20. The second way to pass 
data to the Model Engine 20 is for the Frame Manager 24 to only pass the key information directly to the Model Engine 
20. Then the Model Engine 20 accesses the data directly from the DSS Database 12 using the key information. This 
will be used when the amount of data needed by the Model Engine 20 is quite substantial, ag. a siti^lfon of solving a 
Linear Programming model. The k^ information passed from the Frame Manager 24 to the Model Engine 20 will 

50 indude the focation of the DSS Database 12. among others. 

The Client 314 only interacts with the System Integrator 310 part of the Frame Manager 24. The Functional Inte- 
grator 312 part of the Frame Manager 24 provides the functionality through tfie System Integrator 31 0. The relationship 
between the Functional Integrator 312 and the System Integrator 310 is logically the same as the relationship between 
the Model Ermine 20 and the System Integrator 310. 

55 The System Integrator 310 in turn is composed of the Client Manager 320, the Request tnteipreter 322 and the 
Server Manager 324. The Client Manager 320 manages and monitors the dient connection. For example, it may dis- 
connect a dient if the dienfs machine ^ down or if the cfient is inactive for extended period of time. The Server Manager 
324 manages the server side connection. It is responsfole to start up arxi shut down servers. It is also manages d^- 
parching. The Request Interpreter 322 is the one that the dient (firectly interact with. It wiO parse the dient request and 
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generate request to the servers: W will consutt with the Serv&'Manager 324 before making connection to one specific - 
server. 

The high lev^ object representation of the system integrator 31 0 portion of the F=rame Manager 24 is shown in fig- 
ure 36 and the high level architecture is depicted in figure 37. The implennentation documentation can be found in 
AppencfixC. 

Functional Integration 

The Functional Integrator 312 enatrfes the advanced user to define the supply chain configuration, manages user 
access and privileges, supports and enat)les the customizatkxi of the DSS 10. nnanages domains to support user 
defined data groupings, manages user defined Scenarios 78 and ensures data consi^ency across the DSS 10. and 
dynamically monitors the impact of the user's d^:isions on the performance of the entire supply chain by using siqsply 
chain simulation. 

Supply Chain Configuration 

The Supply Chain Frame f^^anager 24 allows the advanced user to specify the configuration of the supply chain. 
The advanced-user will be able to specify the structural (static) elements of the supply chain. These include: Custon^ers 
or BquTMTient; Products or Repair Items; Components; Production Resources or Repair Resources; For each off these 
structural elements, the advanced user will be able to define the various attrfloutes such as; Names and the values of 
features; Group definitions; and Nodes and locations. 

In addition, the advanced user will be able to define the inter-relationships between these structural el^ents. 
These interrelationships include: Distances, costs, and flow limits on the arcs between the various nodes of the net- 
work; Customer-Producl-Resource (Equipment-Repair Item-Resource) relationship matrix; Bill of Material structure 
that relates conponents to products; and Production Matrix tfiat relates production resources (repair resources) to 
products (repair items). 

The data flow diagram associated with the Stpply Chain Network Configurator 330 is shown in figure 38. 
User Access arti Privileges 

The DSS 10 is a secure system where a userid and password are required for access and is managed by a User 
Access and Privileges Manager 331 . An account consists of a userid, password and membership in various groups. A 
user derives rights from group membership tfiat can be individually amended. The DSS System Administrator is 
responsible for assigning each user to a group and assigning rights to every new account. The lowest access possible 
allows read only access to one spedfrc frame, with no abiBty to save Scenarios 78 or domains. Each tat)le in the DSS 
10 database 12 has a designated owner. Only the owners are allowed to update the DSS Datat»ase 12. A scenario can 
be used to update the DSS Database 12 when the user who generated it is the owner of the data tat)le that needs 
update. 

Customization 

The DSS 10 is customizable to tfte application arxJ environmern wfiere the tool will be used. The customization 
involves: Terminobgy and nomenclature, Modiies and models in the Model Engine 20, Displays and reports, and 
Graphical l^er Interface objects. 

The first two aspects of customization are administered by the armtyst/^ystems administrator. For the last two 
points of customization, the user has the ftexftMlity to customize cfisplays. reports and GUI objects. The DSS 1 0 uses 
the proper terminology in the User Interface 18 for the information presented to be dear and intuitiva The DSS 10 con- 
forms to the user's environmerrt and nomendatura The DSS 1 0 uses a taUe off terminology to implement the nomen- 
clature suitable to the user's application ervironnient trnages on butb^ 

local environment at either tfie time off installation or executioa Saeen appearance elements, such as colors and fonts, 
are rTxxjifiat)le through a User Preferences window. The user has the abOity to change the layout of screen elements. 

Domain I^Aanagement 

The Sippty Chain Fraine Manager 24 provides the user with tf^at>i]ity to d^e corn^^ 
ers, and resources to t>e reused in the context of various analyses. These are caOed Data Domains and are mariaged 
by a Domain Manager 332. 

Data Domains provide a conveniem nrtecharusm for the user to define tfm products and custonri^ 
is interested in working. For exanple, an account mar^ger can deline a data domain that consists of ftre custorrter 
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accountsit^Ks)he s responsSsle for. A data domainis a sel of customer, product or resource combinations; Data 
Domains may t>e used from different Fran^ 1 6. The data domain can be defined at various lev^ of aggregation (res- 
ohjtion) along each dimension: Product/jxoduct group, customer/customer group and resource/resource group. A data 
domain is Independent of a data source (forecast point of sales, shipments). The data sources are determined by the 

5 type of analysis that is performed arxi are therefore contingent on the frame wtiere the data domain is used. For exam- 
ple, a domain can be used in tfie context of the sales promotion analysis functionafity and could also t>e used for fore- 
castirtg: different data sources wiD be used in order to perform each analysis but both refer to the same data domain. 
Mot attaching a particular time range or data series to the Data Domair^ faci&tates their portability from function to func- 
tion and frame to frame. The user is allowed to build, edit and delete Data Domains that are owned by tfie user. In addi- 

10 tion. the user \s allowed read^ccess to the definitions of the Data Domains of other users. This facilitates a set of users 
to perform similar analyst and share carefully constructed Data Domains. The Data Domain Database conprises two 
tat)les: Domain Description and Domain Definition. From these two tables, the list of available user domains and the 
member tuples of each domain can be aeated and displayed for the user. The domain management interface can con- 
sist of multiple tree-viewsw Each tree-view represents the logical grouping of custom^ products or resources. From 

IS each of the tree-views, the user can select the product customer, or resource combinations and add the selection to 
the domain. The Lteer Interface 18 should optionally reflect the data avaflabifrty, and the intrinsic relationship between 
the customers, products, and resources. For example, if the user chooses a specffic customer first he should be able 
to choose only the products that are sold to this customer (or any product, deperxiing on his preference) to make a 
domain. Since a customer (or product or resource) can belong to multiple customer (or product or resource) groups, tiie 

20 user should be able to visualize the groups in which the customer (or product or resource) is a member. This can be 
visually implentented by reversing the tree-view, based on user selected customer (or product or resource). This free- 
reversal wfll (fisplay the bottonvup version of the tree, rather than the usual top<lown. Data Domains can ateo be 
dynamically constructed t>ased on the features of the product. For example, a PSI user can use the domain manage- 
ment tool to deline that a data domain to consists of Televisions with 19" saeen and GR3A chassis. The tool will then 

25 generate a data domain that consists of all the televsions with these features. The data domains contains the data 
groups which a DSS user is interested in working. For example, a plant manager can define a domain that consists of 
products and production resources. An air force commander can define a domain tiiat consists of airaaft and line 
repairable units. The domain can be defined at various levels of aggregation along each dimension. Once a domain is 
defined arxi saved, it can be retrieved and used in the context of various decision analysis. Rgure 39 shows the process 

30 of using the Dormin Manager 332. and also shows the operations of tiie Domain Manager 332. 

Scenario Management 

In the context of the cffferent Frames 16 users generate changes to databases or iristances of visual objects ttiat 

35 can be saved as Scenarios 78 which are managed by a Scenario Manager 334. 

Scenarios can contain: edited data, results of analysis, graphs and charts, and performance metrics 
The Supply Frame Chain Manager 24 supports the fdkMving functions regarding Scenark>s 78: 
Save: Scenarios are saved in the kx:al database 
Load: Saved Scenarios are loaded. 

40 Edit: Saved Scenarios are modified. 
Del^e: Saved Scenarios are deleted. 

A Scenario 78 can be used to update the DSS Database 12 when the user who generated it is the owner of the 
data table that needs update The Supply Frame Chain Manager 24 maintains the data consistency aaoss the entire 
DSS 1 0 by restricting the update of the DSS Database 1 2. Scenarios 78 have note fields to alkw the user to enter free 

45 form comments. Scenarios 78 should have a date stamp to irxticate the time of last modifkation. Scenarios 78 are typ- 
ically defined within a frame and are ^sodated with a user. Scenarios 78 are specific to users but can be acc 
the context of different Frames 16. provicfing that the user has the adequate access privileges. This enables the output 
of an analysis in one fraxne to k>e saved as a scenario and used as an input in the context dS anotfier frama Scenarios 
78. while belonging to speofk; users, can be shared between users. A scenario may be deleted only by the i^er who 

50 created it or the system adminisfrator. A user shouU have the facility to load the scenark> from different vtrorkstations. A 
user should also be allowed to load portions of a scenario into a cfifferent frame. For example, a user is able to save the 
top-down and bottom-up forecasts from ttie Demand Management Rame 1 30, and k>ad the top-down forecasts in the 
PSI Firanrte. The DSS 10 shouU warn the user in case of data irKX>rTY>ata^^ modeteandthe 
parameters that were used to mocfify loaded data. The user is tfien able to apply these models and paranieters to dif- 

55 ferentdatas^ 

A frame 330 has several forms 3^ associated with it as depicted in figure 40. If the user attempts to dose a form 
on which data 334 has been changed, the user will be pronpted to Save the changes to a scenario. At>andon Changes, 
or Update the actual databasa Updating the actual datat>ase requires necessary access privileges. A Scenario 78 is 
anchored to a frame, and can have mutt^ forms ^sodated with it A Scenario 78 can be k>aded into the frame to 
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• ' ~- — whk:hrt is anchored; in whk:hcase,'aIhthe<iata'a«J^ -h- , . 

locations. Attematety, a Scenario 78 can be opened to access specific data that are contained in the Scenario 78. Th^ 
feature wfll enable the user to load the data aeated in a different frame to a different frama To facflrtate this impienrren- 
tation, fomns are specified to have a pre-specified nunt>er of data-'pockets." Bements of a scenario include: 
5 Headerinfornriationforeachof ttie data pockets in each of the forms of each of t^^ For example, DM- 

1-[1]=POS1245=Point of Sales Information May 25. 96; DM-1-[2]=TD1245= Top Dawn Information May 25. 98; and 
DM-1-[31=BU1245= Bottom Up Information May 25. 96. 

Model and parameter information. For example. ARMA with (1.1) applied to Top Down data. 
Graph and parameter information 
10 User comments 
Datestanp 

Performance monitoring using simulation 

IS T\M> levels of integration required in supply chain Decision Sufsport Systems have been embedded in our DSS 
architecture; data integratkm and dedson integration to provide a Network Simulator 350 (see figure 37). The former 
has been obtained by having a common Decision Support System (DSS) Database 12. from which input data to the 
decision models are retriev^ed and outputs updated. By having such bi-directional data f k)ws between models and the 
Dat^t>ase 12a complete data level integration is realized. In order words, aO decisions are based on consistent and up- 

20 to^date information. This is the primary level of integration for a supply chain DSS 10. 

The secondary level of integration e the decision inteyation. The purpose is to avoid sul>-optimization among func- 
tional processes. An ideal case would be to have a "meta analytical decision model' which could optimally solve the 
entire supply chain wide problem. With the state of the art in decision sciences and computing, this is not . Thus, in our 
DSS architecture, various Frances 1 6 are Bnked by the performance simulator. For instance. Forecast Data 1 46 from the 

25 Demand Management Frame 130 is used in PSI planning and VMR 250 frames, VMR schedules are entered to the PSI 
planning and so on. With thte approach, it is necessary to have a supply chain wide performance simulator to rTX>nitor 
the effects due to the systems dynamics ak)ng the supply chain to provide a functional integratk>n. The purpose of such 
an integration is to provide the user visibility beyond his functional boundary in order to facilitate a feedback control. This 
feedt)ack will make it possa>le to dynamically monitor the impact of his decision on the performance of the entire supply 

30 chain. 

The d^cussion bek>w begins with background on deciston integration and the system architecture. Then, the 
underlying supply chain simulation rrradeling logic with regards to data fbw arvj process flow are desaibed. Finally, 
originality of such an approach to use a supply chain simulator for the DSS integration is discussed. 

35 High Level Architecture 

The Simulator 350 resides at the Sipply Chain Frame Manager 24 as a Functional Integrator 31 2 together with the 
Network Configurator 330 and Domain Marager 332 as shown in f^e 37; Supply Frame Chain Manager - KBgh Level 
Architecture. The Simulator 350 can be initially configured with productfkw, n^work structures and domain tn<brmatk)n 
40 with the other irwdules of the Functional Integrator 312. Thea the Simulator 350 will read major decisions from the ind- 
vidual Frames 1 6 tfiat will have inrpact on the total supply chain perforniarx;a Monte Carlo a 

driven by demand processes captured from the domain information and replenishnnent and PSI decisions from the DSS 
Frames 16. Total systems peribrmance representing the supply chain dynamics will be tracked according to the per- 
formance matrices specified in our DSS specification. These mainly cover cost and service tradeoffs including f 31 rates 
45 and response times. The performance will be nrx>nitored in aggregatk)n according to various levels such as; nodes, ech- 
ekxis. distraMition channels and the total system. In essence, the architecture fadfitates the primary objectives of conr>- 
^ . plenieritirigdedskm integration anx>rignriodels to provide a cross-funct^ 

User Interface 

50 

User Interface 1 8 of the performance Simulator 350 wiO have ttiree maja features; network configuration, decision 
and parameter settings and the sinrtilation and monitor in g. 

Network Configurator 

55 

The system wQl invoke the Network Configurator 330 module of the Functional Integrator 312 at the Supply Cf^ 
Frame Manager 24. DetaOed features and User Interfaces have been descritjed in ttie previous sectk>ns. 
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c^.^ ~ Decision and Parameter Settings - * - « ... . - 

Parameter, frame decision settings and ennptrical demand distributions wfll be displayed In the edrtat^le saeens. 
These saeenswOl also be accessible during the simulation run so that the can intem^it the execution and nxxlify 
5 the param^ers interactively. The foncwing screens are included: Demand distribution screens and Frame decision 
screens. 

Performance Monitoring and Simulation 

70 The user is able to visualize the impact of the decisions taken at the level of one frame on the overall performance 
metrics of the entire supply chain. The Supply Frame Chain Manager 24 supports this performance monitoring func- 
tionality. In all the Frames 16 users can easily access the "performance monitoring screea" The performance nronitor- 
ing screen displays global performance metrics that are available to all users and ttiat cannot be deleted or nrxxiified. 
The performance is tracked and displayed ak>ng the: channel (such as VMR. NorvVMR, etc.); echelon (such as sup- 

T5 plier, plant DC and stores); individual nodes; arxl the total system. The performance monitoring screen also contains 
user fonmulated perfonnance metrics that are customizable and available only to the user who formulated them. 

The Supply Frame Chain Manager 24 stpports the fbltowing functions for user formulated perfonmance metrics: 
Formulate: a new user-formulated perlonnance metric. Edit: an existing user-formulated performance metric, and 
Delete: a user-formulated performance metric. The function "edif and "delete" are restricted to the user who defined 

20 the performance measura 

The value of the performance measures can be updated each time the user modifies the value of a field in the local 
database associated with the frame in which the user s working or by using an explicit recalculate function or at user- 
specified time irrtervals. 

Users can choose "a ticker-tape" to always cf splay the current values of user selected key measures. 
25 The User Intertace 18 is designed to support the conventional "Visual Interactive Simulation (VIS)" approach. 
According to this approach, the simulation can be carried out not only in the batch mode but also in the event-by-event 
or period-by-period mode. The performance m^rics could be viewed and parameters adjusted interactively. To fadlitate 
this approach: 

Inventory, service level and cost profiles for each aggregated measure (such as node, channel or echelon) will be dis- 

30 played as time series grapha Thfe will highlight the systems dynamics along the chain. 

Summary performance matrices will be displayed in the summary report screen or saved to a file. 
Simulation Logic: Data Row Description 

The supply chain simulation model primarily mimics the niaterial and information flow controlled by the frame deci- 
sions afong the supply chain (see figure 41). The Simulator 350 ^ built around data tables for each node which are 

35 linked acoorcfing to the information and product ftow. These data tables are stored as simulated data in the system. 

In the initialization phase, tiiese data tables will be populated with inverrtory information indudir^ Inventory posi- 
tion, on hand, on order and schedule receipt Thea these tat)les are connected using pointers according to the network 
structure, order and product flow directions. Then, demand and lead time information is foaded from Demand Manage- 
ment Frame 130 through system integrator and appropriate distribution is built Using the disbibutions, o^tomer orders 

AO are generated accordng to the derrand processes at the customer facing echelon and replenishments are triggered 
according to the control rules afong the logstics ppe line for each event due tima 

The major inputs required are the dedsfons that will effect the total performance of the supply chain. The following 
are included: FGDND or Networtt Configurator - Network design and Product ftow; Demand Management - Forecast 
and forecast errors; Vendor Managed Replenishment - Replenishment policy, Target inventory, and Delivery frequen- 

45 des; PSI Planning - P* line and its variation, and r line and its variation; Supply Managentent; and Component inventory 
policy and parameters. 

. Depending on the configuration of the n^worK other 5if)ply chain system paran)eters such as FG inventory pdicy.and 
parameters may also t>e needed for the non-VMR channel. 

The outputs from the rnodel are based on the perfornriarK^e assessment plan of the DSS 10 for a commercial setting 
50 induding the fdlowings: Supply responsiveness. On-time delivery performance Rll rate, FG inventory levels. Compo- 
nent inventory levels. Order cyde time, arxl Rnanctal measures. 

The Simulator 350 builds up the atX3ve performarK:e metrics from the event-level (lowest) measures. This Tx^ttom- 
up" approach in simulation makes it possble to support user fomulated performance matrices that will be custonrvza- 
Ua 

55 Simulation Logic: Process Ffow Description 

A more detaOed process flow of the simulation engirt can be described in terms of either the demand processes 
or the control rules. Two basic control rules considered in our DSS 10 are production (recond&ation) polides and 
replenishment (inventory) polides. 
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Demand Processes ----- — - . . * - - 

The performance of the total supply chain mainly depends upon the control policies and paran>eter settings along 
the multilevel material and information flows from the supplier to customes. Both independent and depends demand 
5 processes will be sipported. They cfictate the way requirement at each node is generated. In the independent demand 
customer orders are generated for ail nodes from random distrbutions developed from the Forecast Data 1 46 at each 
noda In the dependent case, customer order generation from the rarxiom dtstrOxition is applied only to the customer 
facing echelon. The demand for the higher echelons are calculated from the lower ones with the lead time offsets. 
The following systems will be driven by independent demand processes: Venda Management Replenishment 
w (VMR); Continuous Replentehnrrent (CR); Reorder Point System (r. Q); Just-in-time (JIT); and Min-Max (s, S). 

The following systems will be driven by dependent demand processes: Distribution Requirement Planning Systenre 
(DRP): and Materials Requirement Plarviing System (MRP). As for the case of One-for-one (S-1. S) system for the 
repair systems, Poisson demarxi process will be applied. Demand generation will be carried out by an inverse transform 
of the specified distrfoution. For high volume items, normal approximation of forecast error will be used. For the others, 
75 enrpirical cfistrOxitior^ will be used. Time series forecast and its enor (fistrfoution (or parameters) will t>e obtained as 
frame dedsior^ from Demand Managen)^ * 

Replenishment Processes 

20 Both pull versus push controls are sipported. In the pull control system, inventory is depleted by demand and 
whenever it reaches the replenishment point an order is placed to a supplier. In the VMR, the supplier places a reverse 
order to the store. For the demand channel, inventory decision processes (nxxiels) for the following pull systems will be 
included: Vendor Managen^ent Replenishment (VMR); Continuous Replenishment (CR); One-for-one Replenishirient 
(S-1 , S): Reorder Point System (r. Q); and One4or-one system for repair wfll be logically treated the same as the Con- 

25 tinuous Replenishmerrt in the commercial settings. 

For the push (planning) systems a time-phased plan for the planning interval is established and replenishment is 
triggered teased on the requirement schedule receipt arvl on hand inventory. For the demand channel, pull systems 
are: 

Distritxition Requirement Planning Systems (DRP) 
30 Similarly, for the supply channel, the following puR systems will be supported: Just-in-time (JIT); and Min-Max (s. S). 
The push planning systems for the supply channel are: 
Materials Requirement Ptannirig System (MRP) 

Transportation and information flow logic will be embedded in the replenishment processes. The capacity limita- 
tions, cost and lead time for various modes of transportation arxi information flow (orders) will t>e checked to execute 
35 the replenishn^ents. 

Reconciliation Processes 

The proctoction planning logic refers to the way MPS is created. Given a PSI plan 190 for the planning horizon with 
40 possible variation, the system need to track the dynamic outcomes along the supply chain. Th^ will be carried out by 
generating the dynamic demand along the demarKi channel and consolidating them to obtain the sinmjiated S' line. The 
simulated S* Bne (line refers to as the time series sales irrfbrmation) will be checked against P* (production) and r (inven- 
tory) lines of the PSI plan 190 to compute service fdl rates. Then production plan P* line wDI be offset t>y sinuilated pro- 
duction lead times. 

45 Once the actual P' line is established, conrponent usage can be computed using the Bill of Material (BOM) tables. 
This usage is translated as requirenDents (d^nand) to the sipply channel. Then, corrponent flows afong the supply 
channel will be traced according to the respective conrponent replenishment policies and demand processes at each . 
node follGwing a similar logic as descn'bed in the demarxi channel. 

50 User Interface 18 

One of the primary objectives of our DSS 10 is to provide a decision support environntent that fadfitates the ded- 
sion-nrtaking processes using quantitative inodelsarKj associated business da^ interactfon between the isers and 
the DSS 10 during the dectston-making process can t>e characterized as folfows: The comnujnication of process infbr- 
55 mation and management input Fbrmilation of decision problems; Generation of problem solutions or e^^aluation of 
decision attematives; and Cooncfination of the atxTva 

To fadOtate ttie communication arti coordination between the users arxi the DSS 10, it is necessary to choose the 
appropriate User Interface 18 design paradigm. 
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User Interface Design ParacSgm-^- ' • " ^ - 

The User Interface 18 is based on the coiiventiorml human cbniputer interaction paradigm referred to as "direct 
manipulation". In this paradigm there is no dear separation of input and output Fa example, in exercising a certain 
5 model the user may either evaluate the impact of a decision option tsy specifying the decision variat)les or generate the 
optimal values of the decision variat)les. In the former setting the decision variables serve as input while, in the latter 
setting, the decision variables constitute the output 

Another characteristic of the direct manipulation paradigm is the quick feedback feature where a user initiates an 
action such as posing a particular query through direct manipulation of some interface otsject and the system responds 
10 with reasonable speed. 

User-DSS Interaction 

In each Daemon Support Rame discussed previously, the i^ers will be aided in making several decisk>ns. The 
15 principal process underlying these decisions wiD serve as tf« basis for the design of the User Interface 1 8. 

A typical user-DSS 10 interaction (see figure 42) begins with the users reviewing 402 tfte initial conditions and 
default values related to a decision problem retrieved from the DSS Database 12. Then the i^ers communicate their 
prefererYces through proper selection of options, specification of parameters and values, and choice of artalysis rou- 
tines. The DSS 10 examines the inputs provkied by the users and ^s^ the users in resolving any inconsistency in 
20 the inputs. Then, to fook for the solution of the problem, the DSS 1 0 invokes the decision logic 76 of the frame. The Sup- 
ply Chain Frame Manager 24 associated with the frame executes the appropriate quantitative models and routines in 
the Model Engine 20. The users can review tfie output through the User Interface d^lay. and repeat the above process 
if warranted. 

The general gukielines for the preferred User Interface design are described in the next subsection. 

25 

Design Guidelines 

The general design guidelines are as folkiws: 

30 User Friendliness 

Inturtiveness: Conformance to establshed starxlards. 
Integrated graphical display: Simple and v^ualty dean graphical screen layout 
User customization: Ability to customize the interface irrto user's desired style. 
35 Minimal typing: Use of menus, pull down lists arxi txittons. 

User Guidance 

Rexft)le sequence control: Ability to access the DSS 10 furKtionality without a pre-imposed sequence. 
40 Context-sensitive on-line help. 

Semantic feecft>ack: Use of visual and audk> cues for confirmation and progress. 
Use of cofors for darity. focus and aestheticsw 

User Interaction 

45 

Data visualization: Visual aids to interpret data. 
* Object orientation. . . . 

Local/lremote concurrent usaga 

Single/groif) usage. Ability for muttple users to collaborate in decision making. 
50 Multiple levels of user expertise: Support for r>cvice as well as advanced usera 

Implementation Principles 

Consistency: Similar look and feel** for userinterface objects aaoss the DSS 10. 
55 Modularity: Reusat)te and object-oriented user-interface code. 
CortfigurakMlity: Adaptatxiity to tf^ specifk: user environmerrt 
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Design □ements .... ^ .n t-.^.: 

The key design elements for the DSS User Interface 18 include: Frame GUI: and Standard Object Lbrary. 
Frame GUI: Since the DSS 10 will be an interactive envirortment. we adopt the nrK>st common environment used for 
5 interactive computing, knmn as the WIMP environment which stands for Windows. Icons, Menus, and Pointers. A 
frame-spedfic graphical User Interlace (GUI) in this environment Is necessary to support the interaction between the 
users and the DSS 10 in a decision process. The Frame GUI is customized using a standard set of User Interface 
objects. An example of this Frame GUI Is given in figure 43. 

Standard Object Library: The standard set of the User Interface objects used to build Frame GUIs is contained in a 
70 standard object Ibrary. The forms, positions and contents of the objects are set according to the specific needs of each 
Rame GUI. For example, these are the sample objects in the starvJard library employed in the PSI DSS shown in figure 
43. 

Selection: to choose anvmg various action options 
Grid: to input data and display results 
15 Chart to display input data and results graphically 
Commarxi Button: to execute an action 
List Box: to list user choices 

Example Implementation Architecture 

20 

The basic otsjective of the DSS 10, is to provide customized dectsbn support for the decision makers to manage 
an integrated agile supply chain. It generates the following two specific systems requirements: DSS 10 should provide 
decision support capabilities that work with the prevailing information systems which is mainly data transaction based 
systems. These decision SLf)port capabilities may include data analysis, decision process modeling, scenario manage- 
rs ntent among many others: and DSS 10 must integrate data from various sources along the Supply Chain Information 
Systems 15. This requires the DSS 10 to interact with multiple infonmation systems to gather raw data and distribute 
processed data. 

These two basic systems requirements nrartivate the architecture and the choice of the platforms. 

30 Three-tier DSS Architecture 

In an enterprise-wide supply chain, the potential users of the DSS 10 are decision makers witti different operational 
responsS}iIities arxJ concerns. The views about tfie supply chain and functional requirements for decision support may 
therefore vary accordingly. The data to support these functional requiren^ents reside often on a number of tnforn^tion 

35 systems possfoly with different hardware arxJ software platforms. Consequentiy. the DSS 10 needs to interact with the 
users through a unified User Interface 1 8 to address diverse business concerns while it should also be capable of inter- 
facing with cfifferent Supply Chain Information Systems 15 to gather and distribute data. 

To that end. we have developed a layered systems architecture design fa the DSS 10 as shown in figure 44 in 
which all me^or system components interact with each other in a layered fashion. Aside from other ben^. the layered 

40 design makes the dhoice of platforms as well as implementation of individual system components relatively independ- 
ent and perniits standardized interfaces among varfous system components. The DSS archite^ 
as a three-tier architecture consistent with the commonly understood three^ier dient-server information systems archi- 
tecture consisting of the User Interface 18, the Business Logk: 350 and the Data Management tiers 352 as illu^rated 
in fi^re44. 

45 Each of the three tiers in the DSS architecture has its distirictive functional roles and presents var^ 

system complexitiesv The platform for the three tiers is preferably chosen to best fit the user's unique functional and sys- 
tem neecfe. The chofoe is complicated, by the availat)ility of a number of competitive software arxi hardware platforms 
and the realization tf^ there may not exist a single "optimal" suite of platforms. In the following, howe^. we descrfoe 
a suite of platforms that can best serve tfie gerreral DSS 10 needs and also be in line with the forecasted future devel- 

50 opment trends in information technofogy and enterprise-wkf e distributed computing tecfmology. 

Selection of DSS Development Platforms 

To support the supply chain wide decision making, the DSS 10 needs to be integrated, ftexfoie, responsive and 
55 comprehensiva One major obstacle, however, is that most of the data required by the DSS Database 12 are stored in 
various Supply Chain Information Systems 15 that are based on an older information and computing technology, 
designed to support vertically integrated organizations, built in isolation, and usually very complex. Such systems are 
generally referred to as the legacy systems. Therdbre. to me^ business and systems needs, the DSS 1 0 environment 
should: provide conrunon and e^ understood interfaces to all users, enhance the current business knowledge and 
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skins, model and incorporate business logic, and pronnote access to legacy dala and application systems in a secure*'' - 
manner. 

The development platfewm environment 370 fllustrated in figure 45 has been chosen as the prefen^ed environment 
to meet the above reqiirenr^ents. 

5 In th^ developm^ environment 370, Miaosoft Visual Basic 372 is used to build the unified User Interface 1 8 and 
the Business Logic 350 that includes the Frames 16. Supply Chain Rrame Manager 24. system level sendees arxi 
Model Engine 20. Portions of the Model Engine 20 tfiat require more efficient and precise numerical conputatk)ns are 
pr^erably implemented using the Visual C++ programming language 374. 

The Visual Basic codes 372 directly interface with the DSS Database 12. The DSS Datak>ase 12 uses Miaosoft 

10 Access 376 wfiich. in turn, interfaces with the Supply Chain Information Systems 15 through either Windows ODBC 
(Open Datat)ase Connectivity) tools 378 or Microsoft SQL Server 380 in a dientAsen^er fashion. The Supply Chain Infor- 
mation Systems 15 can include data servers in IBM SQL/DS, UNIX Oracle, among other formats. 

The Windows NT 382 is operating systems for the local area network server while the User Interface 18 can be in 
any Windows environment (3.1 and above) 384. 

IS In this environment it is important to establish the dient/server data finkage between the DSS Datat>ase 12 
(Access engine) and the supply chain information system data servers. 

As desabed earfier, the DSS Database 12 is internal to the DSS 10 implementation and contains only the data 
needed for the execution of the DSS 10. The data in the DSS Database 12 is synthesized from a variety of sources in 
the Supply Chain Information System 15. The DSS Database 12 can be interfaced in a Client Mode 30 to the supply 

20 chain information sources for data retrieval and update, as needed. This dient-server interface, rather than a hard link, 
has the advantages (fscussed below. It ensures that the DSS 10 can be linked to the heterogeneous information 
sources in the supply chain. This is particularly significant in the at}sence of an enterprise-wide integrated information 
system for the sif)ply chain. It reduces the burd^ on DSS Database management by obtaining updated data only 
when necessary. It fosters independence of the DSS 10 for easy maintenance It fadlitates devetopment of the DSS 10 

25 for a generic su^ly chain architecture and minimizes application spedfk; custonnization. 

The architecture descra>ed herein is built upon the general dient-server concept In the follcwing. we describe the 
hardware system architecture (see figure 46) for generic systems, in which the host 398 represents the Supply Chain 
Information Systems 15. and the PCs 400 in tfie Local Area Network (LAfsJ) 402 supports the DSS 10 applications. This 
architecture supports storing the invention descr2>ed herein on various types of storage including RAM. ROM, hard and 

30 floppy cfisks. etc. 

In the architecture of figure 46, we assume that the hosts 398 contain the majority of transaction level data and they 
will communicate with an LAN 402 v^ere the DSS 10 resides. Here, we do not make specific assumptions about the 
type of the hosts (IBM mainframe or UNIX woricstation). On the LAN 402, there will be a server(s) PC 406 and a set of ' 
linked client PCs 400. Specif icalty. the functions of the DSS 1 0 can be partitk>ned as illustrated in figure 47. 
35 Bek]w we descnbe the basic system requirements arxl functions for the system components in the abcve diagram. 

LAN: 

Basic Requirements: 

40 

Local area network supporting standard protocols such as TCP/IP. IPX/SPX, Named Pipes/NetBEUI etc. 
PCs can run Windows NT or 95 

Basic Functions: 

45 

Provide the communication media t>etween client PCs to server PCs 
Pemrnt external PCs to dal into the network using regular telephone fines 
Allm connectk>n to the IBM hosts 

50 Client PCs: 

Basic Requirements: 

Have suff ident speed arxi memory 
55 Have network connectk)n (cn the LAN or dial-up through telephone fine) 
Can run Windows 95 or NT 
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Basic Functions: ^ ^ -.w.w^. — 

Serve as OLE clients 
Provide primary User hiterface 
5 Innplement what-ff scenario nnanager 
Contain localized database 

Server PCs: 

10 Basic Requirenienis: 

Have maximum speed, storage space, memory and network connectivity 
Run Windows NT, SQL Server and SNA Server 

IS Basic Functions: 

Be the OLE server 

Host main DSS Da1at}ase 12 with a Ibrary d SQL queries 

Serve as the SNA Server to exchange data between the DSS DB and host data tables 
20 Implement nxxiel object Ibrary 

Contain external optimization solver 

Hosts: 

25 Basic Requirements: 

Starxlard IBM database arxl applications or UNIX based datat>ase 
Support any combination of the options (Ethernet, Token-Ring, or FDD I) 
SDLC 

30 X,25.QLLC. etc. 

Basic Functior^s: 

Provide raw sippty chain wide trar^ction data 
35 Contain EDI or other connections with ci^tomers and suppliers 
Support overall business information requirement of the company 

Example of 

40 User Access and Privileges 

When the DSS 10 is invoked, the DSS logon diak)g box will be d^played to the user (see figure 48). Failure to enter 
a valid User ID/Password comtxnation results in the DSS 10 immediately terminating. Con^ect entry of a valid user ID 
and password results in the DSS 10 being started and the opening screen being displayed to the user. The user ID is 
45 visible as it ^ typed by the user, but the password is blocked to prevent casual observation while it is being typed. The 
user ID is checked against an internally maintained table to ensure authenticity and user's privilege. 

Opening Screen 

50 Once the user has successfully fogged on to the DSS 1 0, the opening saeen is presented. Presenting the opening 
screen and deciding which frame the user is abUe to access is the responsbility of the Supply Frame Chain Manager 
24. The nnain feature of the opening screen is a graphical outiine of the siippty chain overlaid with the relevant Frames 
1 6 arxl showing the relevant portion of the supply chain. The user may move the mouse pointer over any of tfie Frame 
Boxes aixi dick within the box to launch the frame (see figure 49). 

55 The user rmyateo directly access the Firanies 16 from the Toolbar buttons. The user rru^ 

leges to access the selected group, a an error message wiH be displayed alerting the user that he does not have the 
con-ect privileges. 
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Us^ Preferences - - • - - ^ 

A feature of the DSS 10 avaOable from the main DSS screen is the User Preferences Folder. This folder allows the 
user to change certain features of the DSS 1 0 to pr^eired setting Aspects of the screen appearance, layout and func- 
tionafity wiU be mocfifiable by the user. These prefererves are saved and renienibered between Afferent DSS 10 user 
sessions (see figure 50). 

Domains 

Select Data Domain 

The primary interaction screen for the Domain functionality is the Select Data Domain dialog box (see figure 51). 
The purpose of this dialog box is to display a list of all domains available to the user. H also allows the user access to 
dialog boxes for, editing, aeafa'ng and deleting user domains. This set of functions constitutes the core functionality for 
the domain object 

The major features and functionalities of the Select Data Domain dalog box are discussed below. An area showing, 
in a graphical way. the available domains. This list is buat from two separate lists of domains. One set of domains ^ a 
default list of domains available to all users. The second set of domains is a i^r-spedf ic set of domains. This set of 
domains can be created, edited and deleted by the user. The default set of domains is immutable. Each domain is rep- 
resented by a folder. Double clicking on a folder selects the folder and adds it to the Currently Selected Domain text box 
Double clicking on a folder expands the fotier and shows the customer-product tuples that are within tfie domain. An 
area showing the cunently selected domain name. A button to allow Loading of the currently selected domain. A Cancel 
button to allow the user to exit the dialog box without selecting any domain and wrtfiout initiating a ioad operatioa The 
Cancel s only valid for operations performed on the current dialog box. Editing operation performed during the session 
win persist. An Edit Domain button to allow i^ers to mocfify existing domains, create new domains and delete unneeded 
domains. This functionality is only availalsle for user-created domains and rrat for default domains. 

Edit Domain 

The Edit Data Domain function allows the user to create new. user-defined domains and add them to the list of 
existing domains. In adcfition. the edit domain window allows tiie user to modify existing domains and delete unneeded 
domains. The user can create tuples from a tree-like listing of all available products and product groupings and all avail- 
at)le customer/customer groupings. The user may add as many tuples to the new domain as necessary. The user must 
give ttie domain a unique name and save it It is then added to the list of available domains for the user (See figure 52). 

The major features and the usage of the features of the Edit Data Domain diak>g box are discussed below. To cre- 
ate a new domain, the user must dick the Add New Domain button on the tool bar. This will create a new domain in the 
list of existing domain arxJ open a name change txsx over tfie name of the domain so the user may give the new domain 
a unique nama To add a new tuple to a domain the user must have a selected domain in the domain list Next the user 
masX dick on a product or product group in the product tree and/or a customer or customer group in the customer tree 
and dick the Add to Domain button on the toolbar to add the selected tuple to the selected domain. Only one prod- 
uct/product group and one customer/customer groip may be selected at a time. Selecting a grotp will result in aggre- 
gated data for the selected group being displayed. K data for the members of the group will be needed, the system will 
assist the user by displaying the data at appropriate resolution. However, some analysis may require that all of the data 
for the mennbers be loaded. A shortcut k^ will be provided to altow the user to select all of the products or customers 
that make up a selected group. The user may select as many tuples as necessary. To remove a tuple from the new 
(k>main, the user must select the tuple from the Est of tiples to be added to the new domain and dick tiie Delete button 
on the toolbar. To ddete an entire donrtaiahighligm the domain to be d^ in the list of domains and dick the Delete 
button on the tooft>ar. The user will be warr^ that this action will result in th^ DSS 10. 

If the user dicks OK. the domain is deleted. If Cancel is dkked, the domain wiD not be deleted. When naming a new 
domain: the new domain may not have the same name as an existing user domain nor the same name as an existing 
default domain: and the domain name should be someihing descriptive to the user so he vwll remember what ttie 
domain represents. The user saves the new data domain and exits ttiediak)g bw by selecting the OK button. If the user 
exits without saving the new domain, he/she wai be asked whether the new domain should be saved. The user can exit 
the cfiak)g box without saving the new data domain by ctiddng the Cancel button. Default domains cannot be added by 
the user. Default Data Domains are created and added to the DSS Database 12 by a systems administrator with this 
access privilege. The user may choose t>^een four cfifferent modes for viewing the Customer and Product trees as 
(£scussed betow. The Troduct View" enables the user to first did( on a product or product group in the Product tree. 
When a product or product group has been selected, the Customer tree is updated to dsplay only the ostomers and 
custonrier groups that are rela^ The 'Customer View* enables the user to first ctick on a customers or customer 



105 



EP0770967A2 



group in the Customer tree. When a custonner or customer groi^} has been selected, the Product tree is updated to dis- - — 

play onfy the product and product groups that are relerant The "Cu^omer-Product View" enat)les the user to first dick 
on either an element of the Custon^ tree or an element of the Product tree and see the existing related elements tn 
the other tree. The "TJ^al ViewT displays all customer and customer groups and all product and product groups with 

5 no Enkage betweai them This view allows users to select tuples without regard for the existing relationship between 
the products and a customer. The user also has the abOity to reverse the tree and show all the parental relatior^ips 
involving a selected element of the tree. This is accomplished by way of the Reversed check box located at the top of 
the Customer and Product trees. By cEcking the check box the tree is reversed, based on the currently selected element 
of the tree. Either a group or an incfividual product or customer may be selected. The tree may then t>e rotated to show 

w the groips it belongs to. To restore the view to the normal view, uncheck the check box. 

The user may deselect any seledkxi made In a Product or Customer tree by clicking the Deselect button located 
above the desired tree. This will renrwve the highlight bar from the currently selected tree element and leave all ele- 
ments of the tree in the unselected stat& This is useful if the user wishes to select an element from only one or two 
trees, but not all. 

15 

Make Product Set 

The Make Product Set dialog box gives the user an alternate way to make a domain which only consists of products 
and product groups (see figure 53). Using this diak)g box, the user may select groups of product nurTt>ers based on fea- 
20 tures of the products. This function can be accessed from the Edt Data Domain dialog box by clicking the Make Product 
Set button on the toolbar. This will open the Make Product Set diak>g box. 

First the user selects a product category from the product category BsL Then, the user selects a feature (or fea- 
tures) that will t>e used as selection cnteria(i.e., the Brand) in a combo box in the right part of the dialog box. Once the 
feature selection is made, the possble values for ttiat feature will appear in a list box below the selected feature name. 
25 The i^er may then highlight the features desired. Immecfiately after the feature type (i e-. Brand) is selected, a new 
blank feature type selection box appears to the right of the selected feature type. Thi^ 

feature choice to use as a selection aiteria Q.e., Subtype). Once again, the possft)le values are then listed in a 1^ box 
below the selected feature type and a third feature type selection combo box appears to the right of the last selection 
combo box. This process will repeat until there are no more feature types related to the products. The user may select 

30 all of the choices for the feature by clk:king the Select * button located directly below the Feature Type dialog box. In the 
folkjwing example, the resulting domain consists of products in the "PROJ" product category with brand being "Fl" . "PP" 
or "S" and subtype being "P" or "S". The products that satisfy these selection aiteria are shown in the "Products" list. 

As the user makes selections from among the Feature choices, the list of products matching the selection criteria 
is updated in the Products list box. The user may select a set of these selected products to use as the domain, or may 

35 choose all of the products selected using the Select button. When the user has the desired set of products. OK is clicked 
to copy the selectk>n to the Edt Data Domain dialog box. 

Scenarios 78 

40 Sceriarios 78 are the vehk:le for saving and rek>ading experimental work. From each frame a user has the ability to 
save a scenario to retain the what-ff analysis work performed. Once a scertario is saved, it may t>e accessed t>y other 
users as a means of sharing analysis and planning results among cfifferent users. A sc^iario may ateo be used to save 
tfie logic behind a business decision, so the factors corttrftxiting to the decision may t>e analyzed at a later date and pos- 
sbly reused. 

45 When the user chooses Save Scenario from the RIe menu group, the Save Scenario dialog box is presented (see 
figure 54). At the top of the dialog box is an edit txix shewing the name of the selected scenario the current information 
should be saved ta If the user wishes to create anew scernrk), the nante of the scenario is typed into this ed^ 
the data will be saved under this new scenario nama Scenario r^mes must t>e uniqua 

The user has write access to a Scenario 78 to save the modified information to an existing scenario. Scenarios 78 

50 for which the user does not have write-privileges will appear grayed-out in tfie Save Scenario dialog box, and the DSS 
10willnotalk>wthe user to save to this scenario. The user may also add a description to the scenario and this descrip- 
tion wi 1 1 appear at the bottom of the Save Scenario screen . This is a free text area where the user may type any words 
to descrft>e the scenario. Each time the scenario is saved, the Date Updated fieM of the scenario ^ automatically 
changed to the cun-ent date and time. The scenario is saved when the user cficks the OK button. If the user dicks the 

55 Cancel button, the scenario is not saved. 

If the user w^es to bad an existing Scerwio 78 , the Open Scenario menu choice on the RIe menu is selected 
(see figure 55). Scenarios 78 that were created by ottier users appear with a RO tag, for read only. These Scenarios 78 
may be loaded but cannot be saved. The user may always save these Scenarios 78 to a new scenario, if desired. 
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Demand Management Frame - -a-.— 

The User Interface for Demand Management (DM) Frame 130 provides the user with a consistent environment for 
carrying out these five activities: Demand Characterization: Bottom-up Forecasting; Top-down Forecasting; Sales Pro- 
motion Analysis; and Forecast Performance Evaluation. 

Each of these activities requires a slightly different Lteer Interface to acconpfish the task at hand. Therefore, a dif- 
ferent saeen is used for each, although they will share many common elements, tools, and procedures. Within the DM 
Frame, any number of activities can be operative, however, the user may view only one screenatatima The user may 
change the view from one screen to another without losing any data or configuration information associated with each 
screen. 

All DM activities take place within the same data domain, although different Data Domains may be active in other 
Frames 16 of the DSS 10. The user can select a new data domain for the DM activities at any time using the standard 
DSS 1 0 data domain selectk>n dialog box. 

There are several desirable features common to each of the DM screens. Regardless of the area in which the user 
is working, the user is able to perform the following operations: save and retrieve DM configuration information; save 
and retrieve data from the DSS Database 12; save and retrieve DM data as a scenario; display point-of-sales or ship- 
ment data (where w'icable); specify limits on data time series; specify the resolution of data time series (yearty, 
monthly, weekly); display data as absolute values, or as percentages of some total values; display data in tabular or 
graphical form; dear, cut copy, paste data series within the DSS 1 0 and Windows environment; and apply functions to 
data In a "scratch" or work area. 

Work Area Pop- up Screen 

In additkxi to the defeated screens, a pop-up window is available to act as a scratch or work area. Data series can 
be cut, copied, and pasted to and from this window and either DSS windows, as well as other Windows applications. 
Users can use this window to process arxi analyze data. 

The folkswing sections descrbe each of the DM screens in more detail. 

DemarxJ Characterization 

This area of the demand characterization saeen enables the user to visualize the selected domain in outline form. 
The user can then select one or more data streams at any level of aggregation, and by using the option menu, specify 
the type of data to be displayed: sales history, sales characteristics, or Market Data 140. The Market Data 140 may not 
be always available at the same resolution as the firm's Demand History Data 136. Therefore, spedal "market Data 
Domains" are created to faaTrtate access to the Market Data 140. 

On the right hand side of the grid the user can choose between a set of summary statistics to be displayed: YTD 
Year to date; YTG Year to go; YTDL Year to date last year; YTDB Year to date budget; YTGB Year to go budget; and 
L12M Last 12 months. 

Several analysis toote are avaDable: Trend. Moving average. Pattern changes, Pareto analysis, arxf con^elatk^n 
fc»etween products. The output of these analyses can be displayed in taksie or in graph. 

Sales Characteristics Screen 

A set of Sales Characteristics can be computed and displayed in a special table: average level of demand, trend, 
volatility, and lunpiness. Accessing this table can be done through the menu under 

. Botlom-Mp Forecast ... 

The Bottom-Up (BU) forecast saeen (see figure 56) contains a Customer Table and a Product Table which have 
several configurable cotunvis and data display optbnsw BU operations and functions are accessed from the BU saeen 
menu and subsequent dialog boxes. 

Customer Table 

Since BU forecasting is a cuslomw-<lriven operation, the topmost table displays the customer tree for the selected 
domain. Only those domain entries which are briefly customer-oriented are shown in the custon^ taWa Entries are 
dfeplayed in an outline form as they were dcfned in the domain. The first column in the table lists the names of customer 
groups or customers, wtvle the remaining columns contain the t(^ sales data for that customer. A split line in the table 
(fivkles hstorical and Faecast Data 146. The time spans for historical and Forecast Data 1 46 can be specified by the 
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Customer groups may be expanded or collapsed by double diddng their names in the Customer column entry. 
Product Table 

5 

The bottom table displays all products carried by the selected customer (group). Sales data for each product shown 
is presented in outline form, which may be expanded or collapsed by doUble clicking on a product name. The entries 
beneath each product include actual orders, forward orders, and orientation orders. As with the Customer Tat)le, the 
table is split to show both historical and Forecast Data 1 46. The user may specify the position in the time series for the 
10 historical and Forecast Data 1 46. Promotion periods are highlighted on the cfisplay. 

Total Columns 

On the right side of the Prochict tat)le is three columns which can display a selection of user-d^ined totals from the 
15 following choices: YTD Year to date; YTG Year to go; YTDL Year to date last year; YTDB Year to date budget; YTGB 
Year to go budget; arK) L12M Last 12 months. 

General Features 

20 Promotions periods are displayed highlighted. The impact of promoted verses unpromoted sales can be cfisplayed 
separately in drop-off celte. The mix percentage can t>e used to d^ggregate a forecast generated at the aggregated 
le^el of the customer or custonrier group. Dteaggregation can also t>e done based on the total for the year arxi some 
user defined seasonality factors when the menu option Disaggregate Total year" is chosen. Time series of user defined 
"leading indicators" can be displayed for reference and forecasting purposes. 

25 

Top-Dcwn Forecast 

As would be expected, the Top-Down (TD) forecast saeen (see figure 57) ts similar to the Bottom-Up Forecast 
screen, except that the interface is arranged for product-driven forecast operations. On the TD screen the Product table 
30 appears at the top. while the Customer table appears below it Data display options and forecasting tools for TD oper- 
ations are accessed from the TD screen menu and subsequent dialog boxes. 

ProAjct Table 

35 The Product table displays the list of products from the selected domain. Only those entries which are strictly prod- 
uct-oriented are shown in this table, and are displayed in an outline form as they were defined in the domain. The first 
column in the table lists the names of product groups or individual products, while the remaining coluntns contain the 
sales data for that product agg-egated at the appropriate level. A q?lrt line in the table divides historical arxi Forecast 
Data 146. 

40 Then the user selects a product group or product from the Product table, the fist of customers carrying the prod- 
uct(s) is displayed in the Ci^tomer tabUe as descrfoed below. Product groups may t>e expanded or collapsed by double 
diddng their names in the Product column entry. 

Customer Table 

45 

The txTttom tatsle displays all customers who carry any of the products selected in the Product table. If a customer 
carries all of the selected procfcicts, ft is displayed in a focused font, otherwise it is shown in normal font Sales data for 
each customer ts shonwn. The entries k>eneath each product include actual orders, forward orders, and orientation 
orders. As with the Product tattle, the customer tatsle is split to show txyth historical and Forecast Data 146. The user 
50 may specify the position in the time series for the hotorical arxJ Forecast Data 146. Promotion periods are highlighted 
on tf>e display. 

Total Columns 

55 On the right side of the Customer tatsle are three columns which can cfisplay a selection of user<lelined totals from 
thefollowingchoices: YTD Yeartodate;YTGYeartogo; YTDL Year to date la^ year; YTDB Year to date txjdget; YTGB 
Year to go budget; arxi L12M Last 12 months. 
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General Features • ' ■ - ~ ^ ... 

Promotion periods are displayed highlig^ed. The impact of promoted verses unpronKrted sales can t>e dsplayed 
separately In drop-off ceDs. The mix percentage can be used to disaggregate a forecast generated at the aggregated 
5 level of the customer or customer groip. Dtsaggregation can also be done based on the total for the year and some 
user defined seasonality factors when the menu option "Disaggregate Total Year" is chosen. Time series of user defined 
leacfing indicators' can be displayed for reference and forecasting purposes. 

Sales Promotion Analysis 

10 

The User Interlace that supports Sales Promotion Analysis is built around the promotion calendar. The promotion 
calendar shows the Dst of ail the past and planned promotions for the set of products and customers defined by the 
selected domain. 

For each promotion the foDowing is cfisplayed in the promotion calendar: starting date of the promotion; end date 
15 of the proiTKJtion; promotion type; promotion dass; product being promoted; customers supporting the pronations; pro- 
nrK>tion intertsity; and impact of the pronrxrtion. 

When the user dicks on the promotion calendar button on the toolbar, the pronrotfon calendar Main Display Win- 
dow Is displayed (see figure 58). 

The user can select one or several promotions in the promotion calendar. For these promotions the user can per- 
20 fomn the operations disclosed below. Display shipment and POS Data 138 in table formats similar to the one used in 
BU and TD forecasts. Compute the promotion impact for past pronxstions. Estimate the impact of future promotions. 
Display graphically the impact of the pronrxitions on sales. 

If the user wishes to view the customer-product tuple (domain) that pronxitions are displayed for, or wishes to limit 
the promotfons shown by choosing what Promotion Type, Promotion Class and Promotion Intensity he wishes to ana- 
25 lyze, the Pronrxjtion Selection Wizard may be invoked. The user selects the customer-product pairs that analysis is to 
take place on and can limit the selectfon by choosing what Promotion Type, Promotion Class and Promotion Intensity 
he wishes to analyze. When the OK button is dicked. the Pronxrtion Calendar dialog box is populated with all pronrv>- 
tfons that match the selection criteria (See figure 59). 

30 PSl Frame 

The PSl main screen is a work area where the user can experiment with different Production, Inventory and Sales 
figures and see the effects caused by these cfianges to eventually converge to the most desirat»le PSl plan 190. The 
Main PSl Screen (see figure 61) initially shows the Productioa Inventory arxJ Sales for all of the products in the user 

35 selected domain. The figures for all of the proc&icts are aggregated together and shown. The user way also select any 
individual product in the aggregation and show the numbers for tNs product alone. This can be done by choosing the 
desired product number from the Product selection combo box focated near the top left of the screen. The first choice 
in the combo box is always All Products to alk3w the aggregation of aO products t^ The user may change the 

products being analyzed by selecting a new set of products from all available products. Th^ may be done by selecting 

40 a new domain. 

Directty folfowing the Production (P). Inventory (I) and Sales (S) lines are Temporary P. S and I lines (see figure 60). 

This is a wori^ area where the user may copy and experiment with the real P, S or I figures and nxxlify them to create 

new Scenarios 78. Copy and Paste are enabled on this form so the user may copy tfie original nurTt>ers to the work 

areas. The user nriay also copy a tirne series from another part of the DSS 10 or a separate application to 
45 lines through copy and paste. Lastly, the user may foad data from a saved scenario to the temporary lines on the form. 

The individual cells that connprise the tenrporary work area may be manually edited by the user by dtddng on the 

desired cell and dianging the value in the cell. ^ . 

Also present on the wori( area of the form are Top-Down, Bottom Up, Customer demand infonration. a Top-Down 

minus Bottom Up (TD-BU) and Top-Down minus Sales (TD-S) lines. These lines give the user different and useful views 
50 into the planning data under analysis. These lines are calculated based on the values in the tenrporary P, S and I lines 

of the form. 

The last column cfisplayed on the screen is a sum of the data dsplayed on the sae&i for the ojrrerrt year, 
umn remains on the screen and does not soon lelt to right as other columns are being saoOed horizontally. The tities 
of the varfous horizontal lines of data also does not scroD, but the data series may be scrolled fonward or backward 
55 through time. The month and year assodated with the data are ctisplayed tmmecti^ely above the wortdng area of the 
screen. 
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PSI Reconciliation - - - — 

While working with the data In the temporary P. I and S lines, the user may want to make sure the three lines are 
always consstent This may be accomplished by selecting PSI Reconciliation on the Options menu (see figure 62). 

When selected, a check mark will appear next to this menu choice and the PSI screen will reconcile all data input 
by the user. PSI Reconcfliation 170 functions by updating one line of data based on a new value input into a cfifferent 
lina The user has control over which line gets updated by setting the PSI reconciliation order. 

The user sets the PSI recondliation order by choosing PSI Recondliatwn Order from the Options Menu (see figure 
61). This will open the PSI Reconciliation Dialog Box (see figure 62). From th^ window the can choose which 
line(R S or I) is updated when the selected line is mocfified by the user. In tiie example shown, the I line would be 
updated when the Production line is changed. 

Capacity Checking 

While working with the Production, Inventory and Sales f igures, the user may wish to check the capacity of the 
existing production resources to determine if the current plan is feasible. This is known as capacity checking. This can 
be accessed by clicking the Check Capacity button on the Options menu grotp on the main PSI screen. The main 
capacity checking diak)g tx>x will then be displayed (see figure 63). 

The Options tab allows the user to select the desired plant location arxi the feature of interest and pick ttie existing 
lines that may produce the products with the selected feature The user may remove selected products from the list of 
products that he wishes to analyze The user may select tfie Production resources he wishes to analyze from the Ost of 
avaOable production resources. The user may select tiie key components of the products that he wishes to analyze. The 
user may change the options before performing capacity checking to restrict the scope of the Model Engine 20, and 
after checking capacity for viewing purposes. 

The results tab shows (see figure 64) the results of the capacity checking. For all products selected, a production 
plan is displayed, and at the top of the screen, whettier or not the plan is feasible is Indicated. The capacity checking 
may be viewed product by product or by product group. 

The production resource tab (see figure 65) is used to show the available capacity for ttie selected line for two 
months. If this line has enough capacity, it Is indicated at the top of the screen to be feasible. The user can also see how 
much capacity remains or how much more is needed by looking at the Over and Under lines. 

The Key Components tab (see figure 66) is used to view the Important components required to assemble a final 
product and check whether, using ttie current figures, there sufficient quantity of ttiese components. If too much pro- 
duction requiring one key component is scheduled and ttie part will run out. ttien the key component is indicated as 
infeasible. 

The Bill of Material tab (see figure 67) allows the user to see which components are used In which products. By 
selecting specific components, the user can see which products use the components. 

The Alternative Componarts tab (see figure 68) allows the user to see components that may be sut>stituted for 
other components during production. The user may view the Bst in two ways. By selecting Product, the user can see ttie 
components ttiat are used to assemble the product and any attemative for the components. By selecting Component, 
the i^er can see specific components and any alternative parts that exist 

The Resource Requirement tab (see figure 69) alfows ttie user to see ttie projected production plan for a selected 
assembly fine and product feature typa The user may view ttiis by selecting a line then a product group ttiat may be 
produced on ttie line or by selecting a product group then a fine and viewing ttie schedule for the selected product 
groups. 

Key Conponents Selection 



To analyze production of a product tfie user rnust work witti the componerits that are used to b^ product. The 
user does not need to exhaustively analyze all cornponents, twt just a subset of the corrponents. These are the major 
components of ttie product and are usually refened to as ttie K^ Components. Which components are considered key 
rnay change over time, so ttie user rnust have a way of selecting ttie cun-ert key conrponents. This task is peiformed by 
using the Key Corrponent Selection cfiafog box (seef^e 70). 

The Key Components column of ttie main display area indicates whettier ttie conrponent is a key conrponent All 
key components are also shown in a list at the right of the diatog box. The user may change ttie setting of a corrponent 
or multiple components by selecting ttiem and cficking ttie K^ Conponents button to s^ ttiem to be key or lsk>t Key 
Corrponerits to rnake ttie oorrponents not key. The user nriay sort tfmcorrpon are shown at 

the top of ttie tst by clicking ttie Sort Corrponents button. 

The second column of ttie main display area is a total for a selected range of monttis The default is for ttie entire 
year. The user rnay select a differem range by using ttie moise to highfigm a range of rnorittisan^ Ordered 
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Based on Months button. This will retolat the coluntn for the selected range of months and change the caption for the 
column to indicate the month range sheeted. It will also sort the list of components to show the products from greatest 
ava0at)ility ever usage to l^st ayailak>ility over usage over the selected time period. 

The many features and advantages of the Invention are apparent from the detailed specification and. thus, it is 
Intended by the appended claims to cover ail such features arxJ advantages of the invention which fall within the true 
spirit and scope of the invention. Further, since numerous nxxlifications and changes wiU readily occur to those skilled 
in the art, it is not desired to limit the invention to the exact construction and operation illustrated and described, and 
accordingly all suitable modifications and equivalents may be resorted ta falling within the scope of the invention. 

Appendix A 

Datctbase Specifications for Manufacturing Supply chain 

The folloving are the specif ications of the data tables for the 
mamifacturing supply chain. 

Aggregate Production Plan Data 

Dat:a related to the aggregate production plan for the product and resource 
identified in the APP header 



Field Identifier 


Field 
Type 


Description 


APPHeaderlD 


Long 


APP Header identifier (see aggregate 
production plan Header table) 


TlmePeriod 


Date /Time 


Time period nxzmber 


SupplyOrderXD 


Text 


Supply order pegged to (if 
available) 


Quantity 


Double 


Number of \mi ta of production 


ProposedChange 


Double 


Recommended change in the planned 
quantity (to store changes bet%^een 
regeneration of APPs) I 
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Aggregate Production Plan Header 

Header file for defining the Product X Resource X Time resolutions anri 
values fQ^^^^g|"^^gg^^^^ Pfg^^^^Q^ plans. 



Field Identifier 


Field 
Type 


Description 


APPHeaderlD 


Long 


APP Data Series Identifier 


APPID 


Text 


Identifier for an aggregate 
production plan 


ResourceResolution 


Text 


Resource Resolution: R-Resoiirce, G- 


R** BOUT" 17ft Tn 


Text 


aggregate production plan 


ProductResolution 


Text 


Product Resolution: P-Product, G- 
GroiQ> 


Product ID 


Text 


Product associated with an aggregate 


. TimeResolution 


Text 


D for day; W for week; F for bi- 
%ree)cly; M for monthly; B for bi- 
monthly; Q for quarterly; and A for 
annually. 


Calendar ID 


Integer 


Pegged to a predefined calendar 


DateC±'eated 


Date /Time 


Date when the aggregate production 
plan was created (based on the time | 
resolution) || 


ScenarioData 


Boolean 


Yes if it is scenario data. No 1 
otherwise | 


ScenarioCoimter 


Byte 


Number of scenarios in which this 1 
header participates [ 



Budget Data 

Data for budgeted costs and revenues 



Field Identifier 


Field Type 


Description 


BudgetHeaderlD 


liOng 


Budget header identifier 


TimePeriod 


Date /Time 


Time period number 


TargetRevenue 


Double 


Target revenue in $ 1 


Budge tCost 


Double 


Allocated cost in $ \ 
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Budget Header 

Header file for defining Che Prcxluct X Resource X Customer X Time 
resolutions <not all need be present) for various budgets 



5 


Field Identifier 


Field Type 


Description 




Budget Header ID 


Long 


laentxExer cor cne Buagetiieaoer 




ProductResolution 


Text 




10 


Product ID 








Customer Reso lut ion 


Text 


tJUSuomer iteswxuuiuu i ^ wusuuvncx # 
6 for Customer Group. A for all 




Customer ID 


Text 


Customer associated with the budget 


15 


ResourceResolution 


Text 


P II ■ ■ Jill ipi ■ li Oaa^^ fSW\ * A A#^%^P^*A 

Kesource Kesoxuuxon: tc*tiesoux we ^ u-* 
Group, N-Hode 




ice B oui cc XI/ 


Text 


P^nmii^r** Annn^i.atMl %n.th thft faudaet 


20 


TimeResolut ion 


Text 


w for week; P for bi-weehly; M f or 
monthly; B for bi-monthly; Q for 
quarterly; and A for annually 




Calendar ID 


Long 


Pegged to a predefined calendar 








TVnt'* of mrpation. foir this header 


25 






Y^R if 4 ^ 4 fl flcfiinairio data Ho 

otherwise 




ScenarioCounter 


Byte 


Number of scenarios in which this 

Vi^ad^i^ naT*t'4r*4nat'f^fi 


i 

30 


C^alendar 

Predefined calendars 


to peg the va 


rious data to 




Field Identifier 


Field Type 


Description 




Calendar ID 




Unique calendar identifier 


35 


Date 


Date /Time 


Julian Calendar Date 


DaylTo 


Double 


Unique number for a day in the 
calendar year (typically 1 through 
365) 


40 


WeekHo 


Double 


Unique number for a week in the 
calendar year (typically 1 through 52) 




BiHeekNo 


Double 


Unique number for a bi-week in the 
calendar year (typically X through 26) 




MonthNo 


Double 


Ungiue number for a month in the 
calendar year (typically 1 through 12) 


45 


BiMonthNo 


Double 


Unique niimber for a bi -month in the 
calendar year (typically 1 through 6) 




QuarterNo ' 


Double 


unique nximber for a quarter in the ^ 
calendar year (typically 1 through 4) 


50 


Hoi iday Indicator 


Boolean 


To indicate whether it is a holiday or 
not 



55 
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Coinponent 

Data related to conymenta of the products 



Field Identifier 


Field Type 


Description | 


Component ID 


Text 


Con^onentlD in the planning BOM from 1 
corporate master (e.g. 3317307) 1 


ConponentMame 


Text 


Name of the component | 


MiiiPac)cQuant i ty 


Double 


Minimum pack quantity 


PhysicalParameter 


Text 


Physical dimensions for the 
component 


Coii;>Cate9ory 


Text 


S for Off-the-shelf; C for 
Customized 


Paclragi nglns truction 


Text 


Special paclcaging requirements 



Coniponent Accommodation Matrix 

Equivalence of the key ccwponents to produce different products 



Field Identifier 


Field Type 


Description | 


Product ID 


Text 


SKD nuniber 


Pr imaryConqponent ID 


Text 


Primary conponent identifier 


Al t emat iveCon^onent ID 


Text 


Alternative component identifier 


Quantity 


Text 


number of coo^onents . of the 
Alteimative Component that can 
substitute for one unit of the 
Primary component to product 
Product ID 



Con^Kjnent Requirement Data 

Data related to requirements for the component identified in the header 



Field Identifier 


Field Type 


Description || 


CompReqHeaderlD 


Long 


Identifier for the component H 
requirement header | 


Time Period 


Date/Time 


Time period number | 


Quantity 


Double 


Nuzid>er of units during the time period || 


Proposed Change 


Double 


Proposed Change in required quantity Q 
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CompcmpTit Requirement Header 

Header file def inin g tiie Con^xment X Time resolutions and values for 





various conponent req 


[uirement data 


5 


rxexo xoeiiwxrxer 


Field Type 


Description | 




Coii^ReqHeaderlD 


Long 


Component Requirement Header | 
xaent It xer p 


10 


Component ID 


Text 


Ccnqponent associated %#itb an 
cooipozients requirements plan 




BGMID 


Text 


Unique identifier for BOM 




DateCreated 


Date/Time 


Date idien the coinponent requirements 
plan was created (based on the time 
resolution) 




TimeResolution 




u ror day; w ror weex; F tor ox- 1 
weekly; M for monthly; B for hi- | 
monthly; Q for quarterly; and A for H 
annually | 


20 


Calendar ZD 


Integer 


Pegged to a predefined calendar . H 




APPID 


Text 


Pegged to an aggregate production plan 1 
(if warranted) || 




ScenarioData 


Boolean 


Yes if it is scenario data. No 
otherwise 


25 


ScenarioCounter 


Byte 


ETumber of scenarios in i^ch this 
header participates 


{ 
] 


Component Siqyplier 
Data for the sxj^liar 


of conponents 


Field Identifier 


Field Type 


Description | 




CoRipSuppl ier ID 


Text 


unique identifier for the con^Ksnent 
supplier 


35 


SupplierMame 


Text 


Name of the con^ponent siipplier 




PaymentTerms 


Text 


Example: Net-60 




StreetAddress 


Text 


Street Address 




StatelD 


Text 


Kame of the State 


40 


PostalCode 


Text 


Postal code 




Country 


Text 


Kune of the country 



45 



50 
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Conqponent Supply Contract 

Data associated vith the component supply contract 



5 1 




Field Tvne 






SupplyContractID 


Text 


Identifier for the supply contract 




ContractDate 


Text 


Date of the contract 


1 


NomialLeadTlme 


Text 


Negotiated nominal lead time for a 
defined average quantity 




UnitPrice 


Double 


Negotiated unit price of the component 




QtyDiscount 


Double 


Percentage of discount if the quantity 
is above QtyforDiscount 


75 


QtyforDiscount 


Double 


Minimum size of the Order to qualify 
for the quantity discount . 




MinOrderQty 


Double 


Minimum quantity that can be ordered 
from the supplier | 


^ Conqponent Supply Hode 

Data associated with the component supply node 




Field Identifier 


Field Type 


Description | 


25 


CompSiipplyNode ID 


Text 


unique identifier for the si^ly node U 
(e.g., CVTCabinetNodel) | 




CompSuppl i er ID 


Text 


Identifier of the component supplier 0 




AvgSupplyLeadtime 


Double 


Average lead time to siqpply the 
components (from the time of order) 


30 


SupplyContract ID 


Text 


ID for the Supply Contract (See 
Component Supply Contract Table) 




PreferredCarrier 


Text 


Preferred transportation carrier for 
shipping (e.g., FEDEX) H 


35 


Customer 

Data for individual c 


ustomers 




Field Identifier 


Field Type 


Description 0 


40 


CustomerlD 


Text 


Customer from corporate customer H 
master (e.g. BestP) | 




ShlpToLocation 


Text 


Specific c\istomer location (e.g. DCl) 




DemandNodelD 


Text 


The demand node this customer is 
associated with 


45 


CustoraerName 


Text 


Haroe of the customer 




Address 


Text 


Street address 




State 


Text 


Name of the state 


50 


Postal Code 


Text 


Postal code (Zipcode for domestic) 


Country 


Text 


Name of the Country | 
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Customer Group 

Data for customer groups 



Field Identifier 


Field Type 


Description 


CuatomerGroupID 


Text 


Identifier for the customer groiQ> 


CustomerGroupName 


Text 


Descriptive name of customer group 
(e.g.. Stereo CTV) 


CustomerGroupTag 


Text 


Organizational entity who defined the 
build criteria for the customer group 
(e.g. Marketing) 


Comment 


Text 




ScenarioGroup 


Boolean 


yes if this is scenario groiqp; Ho 
otherwise 


Customer Group Definition 

Table that identifies the parent- child relationship between customer groups 
and customers 


Field Identifier 


Field Type 


Description 


CustomerGroupID 


Text 


Name of the customer group 


CustomerlD 


Text 


Name of the mraber customer (or 
customer group) 
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Customer Orders 

Data for actual custocner orders 



Field Identifier 


Field Type 


Des cription 


CustomerOrderld 


Text 


ID for the actxial customer order (e.g. 
pcec type 1 orders) 


LineitemlD 


Text 


Line item within the order 


Cus tomezOrderRefKo 


Text 


Customer's purchase order identifier 


CustomerlD 


Text 


Customer identified with the order H 


ShipToLocation 


Text 


Ship to location for the order 


Product XD 






Calendar ID 


Long 


Pegged to a calendar 1 


TimeResolutlon 


Text 


D for day; H for week; P for bi- 
weeldy; M for monthly; B for bi- 
monthly; Q for quarterly ; and A for 
annually. 


Or der Bnt ryDa t e 


Date/Txme 


Expressed in terms of the calendar and 
time resolution 


RequestedDate 


Date/Time 


Expressed in terms of the calendar and 
time resolution 


DueDate 


Date /Time 


Expressed in terns of the calendar and 
time resolution 


ShipDate 


Date/Time 


Expressed in terms of the calendar and 
time resolution 


H DeliveryDate 


Date/Time 


Expressed in terns of the calendar and 
time resolution 


R Quantity 


Dotible 


Quantity of the order 


Coninents 


Memo 


Such as value added services 

associated with the order \ 


Customer Product Resource Relationship Matrix 

Table that identifies the Customers, Product and Resources that have 
pairwise relationships 


Field Identifier 


Field Type 


Description | 


ProductResolution 


Text 


Resolution of the product; P for 
product, G for product group 


Product ID 


Text 


Identifier for the product or product 




CustomerResolution 


Text 


Resolution of the customer: C for 
customer, G for customer group 


CustomerlD 


Text 


Identifier for the customer or 
customer group 


Datatype ID 


Text 


POS Data, Top Down Forecast, Bottom Dp 
Forecast 


ResourceResolution 


Text 


Resolution of the resource: R for 
resource, G for resource group 


Re source ID 


Text 


Identifier for the resource or 
resource group _ 
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Demand History Data 

Data for the demand history for the product defined ^" the header 



1 Field Identifier 


Field Type 


Description | 




Long. 


Identifier for a rtemanrt history | 


1 TimePeriod 


Date /Time 


Time period number | 




Long 


Demand Quantity | 


Demand History Header 
Header file defining 1 
various hik^twi his tor. 


tihe Customer X Product X Time resolutions & values for 
Les 


Field Identifier 


Field Type 


Description ' | 


p<MToip/<Hi ftt'Hf*T*i1**r'TP 


Long 


Identifier for a demand history header | 


ProductKesolution 


Text 


P for product; 6 for Product Groap; A 
for all products 


Product ID 


Text 


Product associated with drmanrt history 


CustocnerResolution 


Text 


S for customer ship to; C for 
customer; 6 for customer group; M for 
market; A for all customers 


Customer ID 


Text 


Customer associated with demand 1 
history [ 


TiineResolut ion 


Text 


D for day; W for %«ee)c; F f or bi- 
weeJdy; H for monthly; B for bi- 
monthly; Q for quarterly; and A for 
anmially. 


Calendar ID 


Integer 


Pegged to a predefined calendar | 


DateCreated 


Date/Time 


Date of creation of the header 


S cenar ioDa ta 


Boolean 


Yes if it is scenario data. No 
otherwise 


Scenar ioCount er 


Byte 


Number of scenarios in which this 
header participates 


Demand Node 

Data associated with 


ihe «^oTMTt<j node 


Field Identifier 


Field Type 


Description 


DemnndWode ID 


Text 


Unique identifier for the demand node 
(e.g., SBAB5 or a region) from the 
enterprise point of view 


Deman rtHod eWame 


Text 


Description of dnrwind node 


Comment 


Text 




Demand Orientation Data 

Data associated %fith the dfMnand orientation for the product identified in 
the header 


Field Identifier 


Field Type . 


Description | 


OrientationHeaderlD 


Long 


Orientation Header Identifier 


TimePeriod 


Date /Time 


Date idien the order is projected as 
required 


Quantity 


Double 


Quantity of the orientation 
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Demand Orientation Header 

Header file def ining the Customer X Product X Time resolutions and values 
for various demand orientations 



5 



Field Identifier 


Field Type 


Description p 


OrientationHeaderlD 


Long 


Orientation Header Identifier | 


CustomerResolution 


Text 


S for customer ship to; C for 
customer; 6 for customer group; M for 
market; A for all customers 


CustomerlD 


Text 


Customer identified with the place 
keeping order 


ProductResolution 


Text 


P for product; 6 for product group; A 
for all products 


Product ID 


Text 


Product associated with the 
orientation order 


TimeResolut ion 


Text 


D for day; W for week; P for bi- 
%#eekly; M for monthly; B for bi- 
monthly; Q for quarterly; and A for 
annually. 


1 Calendar ID 


Long 


Pegged to a calendar 


DateCreated 


Date /Time 


Date the header was created 


ScenarioData 


Boolean 


Yes if it is scenario data, Ko 
otherwise | 


ScenarioCounter 


Byte 


Number of scenarios in t^iich this- R 
header psurticipates || 



User and domain description for various domains 



50 



Field Identifier 


Field Type 


Description { 


DomainID 


Long 




DomainMame 


Text 


The name of the domain 


\ DomainOwner 


Text 


The owner of the domain 


Domain Definition 
Domain definitions in 

Field Identifier 


terms of pro 
Field Type 


duct, customer and resource groups 
Description | 


DomainID 


Long 




ProductResolution 


Text 


P for product; G for Product Grouqp; A 1 
for all products | 


1 Product 


Text 




1 CustomerResolution 


Text 


C for customer; G for customer groi^; 1 
M for market; A for all customers | 


1 CustOTier 


Text 
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Featxire Choices 

The various unique values for the different product features -generated on a 
batch basis 



y Field Identifier 


Field Type 


Description 


1 ProductType 


Text 


The type of the Product that these 




features belong to 


1 Feature 


Integer 


Feature of the Product | 


1 Choice 


Text 


N^une of the Feature possibility f 



Forecast Data 

Data associated with forecasts for the product -customers identified in the 
forecast header ■ 



Field Identifier 


Field Type 


Description 


FcstHeaderlD 




Pegged to the Forecast Header' Table 


TimePeriod 


Date /Time 


Time period number 


PorecastValue 


Double 


Forecast data value 


ForecastCV 


Double 


Coefficient of variation of forecast | 



Forecast Header 

Header file defining the Customer X Product X Time resolutions & values for 
various forecasts 



Field Identifier 


Field Type 


Description 


FcstHeaderlD 


Long 


Forecast Header Identifier 


ProductResolution 


Text 


P for Product, G for Product Grov^r A 
for all Products 


Product ID 


Text 


Product associated with forecast 


CustomerResolution 


Text 


S for Ship- to, C for Customer, 6 for 
Customer Group, A for all Customers 


Customer ID 


Text 


Customer associated with forecast H 


TimeResolution 


Text 


D for day; W for week; F for bi- 11 
weeJdy; M for monthly; B for bi- 
monthly; Q for quarterly; and A for 
annually. 


Calendar ID 


Integer 


Pegged to a predefined calendar 


DateCreated 


Date /Time 


Date when the forecast was created 
(based on the time resolution) 


1 ForecastType 


Text 


B for botton-up; T for top-down 


B ForecastAssun^tions 


Memo 


Assumptions associated with the 
forecast 


1 ForecastOwner 


Text 


Author of the forecast ' 1 


1 ScenarioData 


Boolean 


Yes if it is a scenario data; No 1 
otherwise 1 


1 ScenarioCounter 


Byte 


Number of scenarios in which this | 
header participates | 
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Freight Rate 

Table that sumnarizes 


the various 


freight rates 


Field Identifier 


Field Type 


Description . 


FreightSateTable n> 


Text 


Freight rate table identifier 




Text 


Description of the rate table 


naxif e xgnt 


Double 


Maximum weight limit (e.g. truck 
capacity) 


naxwuoe 


Double 


Maximum volume limit 


1 We ignt Category 


Text 


e.g. 0-lOOlb, lOO-SOOlb, etc. 


B mxeageuacegory 


Text 


e.g. less than 100 miles, less rMnn 
500 miles, etc. 


1 HinimumCbarge 


Double 


Minimum charge associated With a trip 


StdCost 


Double 


e.g. $ per hundred wei^t charge for H 
LTL and $/mile for TX. | 


Econoinycost 


Double 


e.g. for fedex economy rate H 


PremiinnCost 


Double 


e.g. for fedex next day service | 


Inventory Data 
Inventory data for it 


ema (products 


or coo^ionents) identified in the header 


1 Field Identifier 


Field Type 


Description 


1 InventoryHeaderlD 


Long 


Inventory Data Series Identifier 


TimePeriod 


Date/Time 


Time period number 


QnHandlnventory 


Double 


On -hand available inventory for 
allocation 


QnOrder Inventory 


Double 


On- order inventory 


BackOrderlnventory 


Double 


Back- ordered inventory 1 


InTransit 


Double 


In- transit quantity y 


Reservedlnventory 


Double 


Reserved inventory on-hand but 
available for allocation only in case 
of emergency 
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Inventory Header 

Header file defining the item (Product or Ccn^Kment) X Time & and values 
for various inventory data 



70 



30 



40 



45 



Field Identifier 


Field Type 


Description 


InventoryBeaderlD 


Long 


Inventory Data Series Identifier 


1 InventoryNodelD 


Text 


Identifier for an inventory logical 
warehouse 


Invent oryControl ID 


Text 


Identifier for inventory control u 
parameters | 


ItemID 


Text 


Product Item ID 


ItemResolution 


Text 


I ten Resolution: C for Cooponent, P 
for Product / 6 for Product Group and A 
for All 


TimeRea oXut ion 


Text 


D for day; W for week; F for bi- 
wee)cly; M for monthly; B for bi- 
monthly; Q for quarterly;, and A for 

annual 1 v 


Calendar ID 


Integer 


Pegged to a predefined calendar 1 


MinlnventoryLevel 


Double 


Kininum inventory level for the it^ U 


MaxInventoryLeveX 


Double 


Maximum inventory level for the item U 


DateCreated 


Date/Time 


Date the inventory header was created 


ScenarioData 


Boolean 


Yes if it is scenario data. No 
otherwise 


ScenarioCounter 


Byte 


Number of scenarios in which this 
header participates 


Inventory Node 

Data associated with 


the inventory node 


Field Identifier 


Field Type 


Description 


InventoryNodelD 


Text 


Unique identifier for the inventory 
node (e.g., ArdenNarehouse2 ) 


FacilitylD 


Text 


Physical Facility identifier 


InventoryCategory 


Text 


Coeponent or FG-Bnterprise 


inventoryBchelon 


Double 


1 or 2 


InventoryNodeName 


Text 


Name for the inventory node 


ServiceLevel 


Double 


Service level for the inventory node 


Address 


Text 


Address for the inventory node 1 


StorageCapacity 


Double 


Physical storage capacity of the 1 
inventory node (in cubic feet for 1 
exanple) 1 
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Inventory Paramters 

Data for the inventory control parameters 



Field Identifier 


Field Type 


Description 


InventoryControlID 


Text 


Identifier for inventory control 
parameters: Assume inventory 
planning » inventory control 


SafetyStockFactor 


Doxible 


Safety stock factor 


TarcretServiceLevel 


Double 


Target service level 


Policyrype 


Text 


Policy type: SS,Min/Max,QR,etc. 


MinlnventoryFactor 


Double 


Minimum inventory factor <e.g.» in 
terms of weeks of sales) 




MaxInventoryFactor 


Double 


Maximum inventory factory (e.g., 
in terms of weeks of sales) 


MinOrderQtyFactor 


Double 


Minimtim order quantity factor 1 


1 CzurryChargeFactor 


Double 


Carrying cost factor | 


OrderCbargeFactor 


Double 


Ordering cost factor 1 


InventoryClass 


Text 


Inventory classification | 


Replenishment 
Frequency 


Double 


Frequency of replenishment w.r.t. | 
the time resolution in the header | 



Market Data 

Data for the meurket defined in the header 



Field Identifier 


Field Type 


Description 


MarketHeaderlD 


Long 


ID for mar)cet header (see Market 
Header table) 


Time Period 


Date /Time 


Time period 


NarketShare 


Double 


Percentage of share held by the 


ConsumerDemand 


Double 


Total dpmand quantity 


AverageSellingPrice 


Currency 


Average Quit Price of the product 


DemandForecas t 


Double 


Forecasted demand | 
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Market Header 

Header for defining the mazlcet {Product X Customer resoltttions) awH values 



10 



20 



40 



Field Identifier 


Field Type 


Description 


MarketHeaderZD 


Long 


Identifier for the market header 


MarketDefinitionID 


Text 


unique identifier for a marlcet (e.g., 
PTV-S) 


HarketName 


Text 


Market Description (e.g. Projection TV 
in Selling floor) 


DataScope 


Text 


Suitable tag: Brand name (e.g., Sony) 
or industry-wide 


DataSourcelD 


Text 


Source of market data (e.g, NIELSBN) 


Timeltesolution 


Text 


D for day; W for week; F for bi- 
weeklv: M for moathlv* B foip hi- 
monthly; Q for quarterly; and A for 
annually. 


Calendar ID 


Integer 


Pegged to a predefined calendar 1 


ProductResolution 


Text 


P-Product, PQ- Product Qroi^, A- All 
products 


Product ID 


Text 


Identifier for the product 


CustooerResolution 


Text 


C-Customer, CO-Customer Group, A-All 


CustomerlD 


Text 


Identifier for the customer 


DateCreated 


Date/Time 


Date the header was created 


ScenarioData 


Boolean 


Yes if it is scenario data; No 
otherwise 


ScenarioCounter 


Byte 


Number of scenarios in which this 1 
header participates | 


Material Delivery Schedule Data 

Material Delivery Schedule for the Component identified in ^^«» header 


Field Identifier 


Field Type 


Description 


MDSHeaderlD 


Long 


Identifier for the Material Delivery 
Schedule Header 


DeliveryDate 


Date/Time 


Material Delivery Date 


Quantity 


Double 


Number of units of material delivery 
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Material Delivery Schedule Header 

Header £ile definia^ the Component X Supplier X Time resolutions k values 
for various material delivery schedules • 



1 


1 Fie±a xQentxxxer 


irxexQ Type 


Descr ipt ion 




MDSBeaderlD 


Long 


Identifier for the Material Delivery 
Schedule Header 




CooponentSupplyBod 
elD 


Text 


Identifier for cocyonent supply node 


70 


SvOTlierlD 


Text 


Supplier associated with a Material 
Delivery Schedule 


IS 


TimeResolution 


Text 


D for day; V for week; p for bi- 
weekly; M for monthly; B for bi- 
monthly; Q for quarterly; and A for 


Calendar ID 


Integer 


Pegged to a predefined calendar 




DateOreated 


Date/Tine 


Date vbmi a Material Delivery Schedule 
was created (based on consistent time . 
units) 


20 


Scenar ioDa ta 


Boolean 


Yea if it is scenario data, BO 
otherwise 




ScenarioCotmter 


Byte 


tlusiber of scenarios in i^ch this 
header participates 


25 


Planning BOM 

Imploded Bill of Material used for Planning 




1 Field Identifier 


Field Type 


Description 1 




BOMID 


Text 


unique Identifier for the planning BGM 
(defined external to the DSS dat2^>ase) 


30 


Component ID 


Text 


unique conponent identifier 




Product ID 


Text 


SK0 nuznber { 




Quantity 


Double 


Number of con^>onents used in SKD \ 



35 POS Data 



Point of Sale data for 


the customer- 


products identified in the header 




Field Identifier 


Field Type 


Description 




FOSReaderlD 




POS Header Identifier 


40 


Time Period 


Date/Time 


Timer period mmber (beginning of 
the time period) 




Selllhrough 


Double 


Sale to end user 




Shipments 


Double 


Shipments from the customer DC to 
the stores 


45 


Receipts 


Double 


Shipments from the vendor (e.g. n 
pcec) to the customer dc | 




DCInventoryStatus 


Double 


Onharrd inventory at the ship to 1 
location (customer dc) 1 


50 


StorelnventoryStatus 


Double 


Aggregate onhand inventory of stores I 
served by the customer ship to 1 
location (e.g. dc) 1 




Store&QnOrderQty 

L , 


Double 


On order quantity from the stores to 1 
the customer dc | 
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POS Header 

Header file defialng the Customer X Product X Time resolutions & values £or 
various POS Data 



5 



IS 



20 



25 



40 



50 



Field Identifier 


Field Type 


Description | 


POSHeaderlD 


Long 


Identifier for the Point of Sales 
Header 


CustomerResolution 


Text 


Customer Resolution: S for Customer 
Shipto, C for Customer, 6 for Customer 
Group, A for all g 


CustomerlD 


Text 


Should be a valid customer group or a R 
null set (e.g.. Selling floor) 


ProductResolution 


Text 


Product Resolution: P for Product. G 
for Product Group, A for all 


1 PrbdiictlD 


Text 


Product associated with the POS Data ~ 


1 TimeResolution 


Text 


D for day; W for week; P for bi- 
weekly; M for monthly; B for bi- 
monthly; Q for quarterly; and A for 
annually. 


1 CalendarlD 


Long 


Pegged to a specific calendar V 


N DateCreated 


Date/Tiioe 


Date the POS Header was created or | 
modified 1 


ScenariOData 


Boolean 


Yes if it is scenario data; No 1 
otherwise 1 


ScenarioCounter 


Byte 


Kumber of scenarios in which this g 
header i>articipate8 | 


Product 

Data for end products 






Field Identifier 


Field Type 


Description 


ProductID 


Text 


SKD from corporate item master (e.g. 
RR1330N) 


ProductName 


Text 


Kame of the Product 


ProductCategory 


Text 


Product Category 


Featurel 


Text 


Exan^le : Brand 


Feature2 


Text 


Example: Screen size 


Feature3 


Text 


Bxanple: Audio: M-Mono, S -Stereo, P- 
Prologic, D-Dolby Prologic | 


Feattire4 


Text 


Example: Subtype 1 


Features 


Text 


Bxanple: Cabinet type H 


Features 


Text 


Bxanple: Chassis type 1 


y ProductDescription 


Text 


Description of the product | 


SKDSize 


Double 


Hundber of product xtnita in a SKD 
(e.g.l) 


Physi calDimens ions 


Text 


Height X Depth X Width 


Height 


Do\ible 


Weight of the SKD | 
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Product Features 
The feature list of the products 



i Field Identifier 


Field Type 


Description . | 


H Product Category 


Text 


Product Cateczorv 1 


1 FeatureNumber 


Xjong 


Feature Field Ruster E 


1 FeatureKaste 


Text 


Feature Kama Description | 


Data for product grou 


1 








iiescrxpcxon | 


ProductOroupID 


Text 


Identifier for the product ■ group E 


ProductGroupNnme 


Text 


Descriptive natoe of product group 
(e.g. l9Stereo) 


ProductGroiqpTag 


Text 


Organizational entity idio defined the 
build criteria for the product group 
(e.g. Marketing) 


ScenarioGroup 


Boolean 


Yes if this is scenario group; Ho 
otherwise 



Product Group Definition 

Table that identifies the parent -child relationship between product groins 
and products 



Field Identifier 


Field Type 


Description 


ProductGroupParentID 


Text 


Identifier for the product group 
that is the parent 


Product GroupChi IdID 


Text 


Identifier for the product group or 
product that is the child 



Production Accommodation Matrix 

Table that identifies alternative prochiction resources for producing 
various products 



Field Identifier 


Field Type 


Description | 


Product ID 


Text 


Identifier for the Product 1 


Pr imaryResource ID 


Text 


Identifier for the Primary Production 
Resource 


AltemativeResource 
ID 


Text 


Identifier for the Alternative 
Production Resource 


Quantity 


Double 


Nunber of units of Alternative 
Resource that can substitute for 
Primary Resource to Product 
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Production Capacity Data 

Production Capacity X>ata of the production resource identified in the 
header 



5 


Field Identifier 


Field Type 


Description 




ProductionCapacity 
Header ID 


Long 


Production Capacity Header ID (See 
Production Capacity Header Table) 


10 


TimePeriod 


Date/Time 


Timer period number 




NoShifts 


Double 


number of planned shifts during the 
time period 




LoadingFactor 


Double 


Planned loading rate (e.g. % 
utilization) 


IS 


YieldPactor 


Double 


Target yield values 




DowntimePactor 


Double 


Projected domtime 




CapacityRequired 


Double 


Capacity required 


on 


Ca|>acityAvailable 


Double 


Capacity available 


Production Capacity B 
Header file defining 
for various Productio 


eader 

the Production Resource & Time resolutions & values 
n Capacity Data 


25 


Field Identifier 


Field Type 


Description 




Product CapacityHea 
derlD 


Long 


Production Capacity Header ID 


30 


ResourceResolution 


Text 


N for Production Node, RG for 
Production Group and R for Production 
Resource 




ResoiircelD 


Text 


Resource (Resource, Group or Node) 1 
associated with an aggregate 1 
production plan 


35 


CapacityUnit 


Text 


Example, number of production hours, U 
shifts, etc. (related to the time 1 
resolution) D 


40 


TitneResolution 


Text 


D for day; w for weeJc; P for bi- 
wee)cly; M for monthly; B for bi- 
monthly; Q for quarterly; and A for 
annually. 




CalendarlD 


Integer 


Pegged to a predefined calendar 


45 


OateCreated 


Date/Time 


Date %Aien the aggregate production 1 
plan was created (based on the time 1 
resolution) | 


ScenarioData 


Boolean 


Yes if it is scenario data. Ho | 
otherwise f 




ScenarioCounter 


Dyte 


Number of scenarios in which this | 
header participates | 
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Producticn Matrix 

Agcpregate matrix defining the production rates for Product X Resource 
combinationa 



5 



10 



20 



I Field Identifier 


Field Type 


Description 


1 ProductMatrixID 


Text 


Identifier for the production matrix 


ResourceReaoXution 


Text 


Resource resolution identifier 


Resource ID 


Text 


unique identifier for the production 
resoxurce (e.g., FXXQ) 


ProductResolution 


Text 


Product resolution: C for Component, P 
fn-r p-rrvhif*^ G far Product Groun 


1 Product ID 


Text 


Ukiigue identifier for input product 
(group) 


YieldRate 


Double 


Actual yield rate for the product on 
the resource 


TimeResolution 


Text 


D for day; W for week; F for bi- 
weeXly; M ror mnnrn ly; a tor di- 
monthly; Q for quarterly; and A for 
annually. 


ProcessTime 


Double 


Actual time of production | 


SetupMatrixID 

Production Hode 

Data for the product i 


Text 
on node 


Identifier for the setup time matrix Q 


y Field Identifier 


Field Type 


Description 


Product ionNode ID 


Text 


Dhique identifier for the production 
node (e.g., PTVNodel) 




Text 


Name of the production node 


j ConvDent 


Text 




Production Requiremes 
Production Requiremes 


ts Data 

Its Data for the product identified in the header 


Field Identifier 


Field Type 


Description H 


ProdReqHeaderIp 


Lcstg 


Production Requirement Header 
identifier (see Production 
Requirements Data Header table) 


1 TimePeriod 


Date/Tine 


Time period number 


n Quantity 


Double 


Munber of units of production 
^ 


ProposedChange 


Double 


Proposed change with respect to the i 
quantity 1 
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Production Requlrefoftnts Header 

Header file deflnin? the Product X Time resolutiona & values for various 
Product Reqttir«penf data 



5 



10 



15 



1 Field Identifier 


Field Type 


Description 




1 ProdRet^eaderlD 




Production Requir^nent Header 
Identifier 


APPXD 


Text 


Identifier for an aggregate production 
plan 






Text 


Product Resolution: P-Prodct, 0-Group 




Product ID 


Text 


Product associated with the production 


TixneResolution 


Text 


V for day; W for week; F for bi- 
tieiekly; M for monthly; B for bi- 
monthly; Q for quarterly; and A for 
annually. 


Calendar ID 


Integer 


Pegged to a predefined calendar 


DateCreated 


Date /Time 


Date %dien the production requirements 
plan was created (baaed on the time 
resolution) 


ScenarioData 


Boolean 


Yes if it is scenario data. No 
otherwise 




ScenarioCounter 


Byte 


number of scenarios in which this 
header participates 




Promotional Data 

Data related to past and future promotions for Products & Customers in the 
header 




Field Identifier 


Field Type 


Description 


PromotionHeaderlD 


Long 


Promotion Header Identifier 1 


TimePeriod 


Date /Time 


Timer period number (beginning of the U 
time period) | 


PromotionDuration 


Doiible 


Time duration for the promotion 1 


Pre-evaluationQty 


Text 


Estimate before the profnotion for the | 
sales qty due to the promotion H 


Pos t - evaluat ionQty 


Text 


Estimate after the promotion for the 1 
sales qty due to the promotion n 
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Promotion Header 

Header file defining the Product X Customer X Time resolutions & values for 
various Promotion data 



3 Field Identifier 


Field Type 


Description 


1 PromotionHeaderlD 


Long 


Identifier for the Promotion Header 


CustomerResolution 


Text 


Customer Resolution: S for Customer 
Shipto, C for Customer, G for Customer 
Group, A for all 


Customer ID 


Long 


Should be a valid customer gro^ or a 
null set (e.g.. Selling floor) 


ProductRes olut ion 


Text 


Product Resolution: P for Product, G 
for Product Group, A for all 


Product ID 


Text 


Product associated with ♦'H** promotion 
Data 


TimeResolut ion 


Text 


D for dav: W for weelc; P for- hi- 
%'ee)cly; H for monthly; B for bi- 
tuumun ly ; u cor quarcerj.y; ana A £or 
annually. 


Calendar I^) 




ireggea a specxzxc caxenoar 




Text 


K Eox Kccaixer; ir lor irvzisc; c ror 
Competitor 


Promot ionClass 


Text 


Promotion class (e.g. Price 
Reductions) 


Promot ioniB t ens i ty 


Double 


Intensity of the promotion (low, 
medium, high) 


ProrootionShapelD 


Long 




DateCreated 


Date/Time 


Date of creation of the Promotion 
Header 


ScenarioData 


Boolean 




ScenarioCounter 


Byte 




Resource 

Data related to production resource 


Field Identifier 


Field Type 


Description |{ 


ResourcelD 


Text 


Unique identifier for a production 1 
resource (e.g., FAXG) | 


ResourceName 


Text 


Descriptive name 


ResotirceGrouplD 


Text 


Production group this resource belongs 
to 


MaxLineRate 


Double 


Maximum line rate 


KoHorkstations 


Double 


ITumber of workstations { 


MaxBuf fers 


Double 


Maximum number of buffers 
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Resource Group 

Data related to production resource group 



IS 



1 Field Identifier 


Field Type 


Description 


H ResourceGroupID 


Text 


ntiique identifier for the production 
group (e.g., Plaht4) 


1 ResourceGroupMame 


Text 


Descriptive name 


i ProductionNodelD 


Text 


Production node this group belongs to 


1 Attributel 


Text 


Attribute (e.g.. Category, Location) 


1 Attribute2 


Text 


Attribute (e.g.. Category, Location) 


R Attribute3 


Text 


Attribute (e.g.. Category, Location) 


y ScenarioGroup 


Boolean 


Yes if this is scenario groiq^; Mo 
otherwise 



Resource Group Definition 

Table that defines the parent- child relationship of the production resource 
group and production resources 



Field Identifier 


Field Type 


Description 


ResourceGroupParentID 


Text 


Identifier for the resource group 
that is the parent 


ResourceGroupCbildID 


Text 


Identifier for the resource group 
or product that is the child 



Sales Requirements Data 

Sales Requirements data for the product identified in the header 



1 Field Identifier 


Field Type 


Description | 


SalesRec^eaderlD 


Long 


HeaderlD pegged to the Sales 1 
Requirraent Header table 1 


TimePeriod 


Date /Time 


Time Period pegged to the time 
resolution in the Sales requirements 
header table 


Quantity 


Double 


Quantity required 
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Sales Requirements Header 

Header file defining Che Product X Time resolutiantf & values for t he sales 
requir^nents data 



5 



25 



Field Identifier 


Field Type 


Description 


SalesReqHeaderlD 


liong 


Header ID of the sales requirements 


ProductResolutlon 


Text 


Production Resolution: P« Product, 1 
POaProduct Qroiq>, A^>A11 | 


Product ID 


Text 


Product ID 1 


TimeResolution 


Text 


Time Resolution: D-Day, w-HeeUy, M- | 
Monthly, Q-Quarterly. Y-Yearly 1 


CalendaT'TP 


Long 


Calendar ID [j 


DateCreated 


Date /Time 


Date of creation, of the sales 
requirements 


ScenarioData 


Boolean 


Yea if it is scenario data. No 
otherwise 


ScenarioCounter 


Byte 


Number of scenarios in vrtiich this 
header participates 


Scenario 

Scenario description 


and user information 


i Field Identifier 


Field Type 


Description | 


N ScenarioID 


Long 




ScenarioName 


Text 




User 


Text 




Description 


Memo 




DateCreated 


Date/Time 




DateOpdated 


Date/Time 





35 

Scenario Data Compatibility 

Table that specifies what data headers can be loaded into each of the data 



pockets on each form 


for each frame 


Field Identifier 


Field Type 


Description | 


Frame 


Text 


Frame Name | 


Form 


Integer 


Form Number 


Pocket 


Integer 


Pocket Number 


1 TableName 


Text 


Table name for the (Frame, Form, 
Pocket) triple f 
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Scenario Definition 

The table that contains the header ids of the various data that exists in 
each poc)cet, in each form in each frame for different scenarios 



Field Identifier 


Field Type 


Description 


ScenarioID 


Long 




Frame 


Text 




Form 


Integer 




Pocket 


Integer 




Header ID 


Long 




DateCreated 


Date /Time 




DateUjpxlated 


Date/Time 





Setiip Matrix 

Aggregate matrix defining the sequence -dependent sett^ times- for product 
changeovers 



Field Identifier 


Field Type 


Description 


SetupMatrixID 


Text 


Identifier for the Setup Matrix 


PrevProduc t ID 


Text 


Identifier of the product that has 
just finished processing 


1 Next Product ID 


Text 


Identifier of the product to be set-up 
on the resource 


1 TimeResolution 


Text 


D for day; W for week; F for bi- 
weekly; M for monthly; B for bi- i 
monthly; Q for quarterly; and A for | 
annually. | 


SetupTime 


Double 


Actual time to set up Q 


Si^iply Chain Network 

Structural data specifying the sup 


ply chain network 


Field Identifier 


Field Type 


Description 


LinkID 


Text 


Supply chain netwozic link identifier 


FromNodelD 


Text 


A node ID from any of the three node 
classes: con^xment supply, production 
inventory | 


ToHodelD 


Text 


A node ID from any of the three node 1 
classes: production, inventory, d&nand 1 


LinkCapacity 


Double 


Capacity of the link \ 


Transport Ijeadrirae 


Double 


Transport Lead time associated %rith . 
the link 


n Distance 


Double 


Transportation distance 


Linklndi ca tor 


Boolean 


Yes if it is currently active and in 
use and No otherwise 
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Siq>ply Order Data 

Data for the supply orders identified in the header 



5 


Field Identifier 


Field Type 


Description 




SiqiplyOrderHeaderlD 


Long 


Production or supply order (e.g. pcec 
type 4 orders) 


70 


OrderDate 


Date/Time 


Date of creation expressed with 
respect to calendar 




OrientationDatalD 


Text 


Orientation order associated with 1 
s\^ly order B 




DueDate 


Date/Time 


Date the supply order is due 0 


15 


Quantity 


Double 


Quantity of the siqpply order | 


Supply Order Header 

Header file defining the Product X Customer Z Time resolutions 6 values for 
supply orders 


20 


Field Identifier 


Field Type 


Description | 




SupplyOrderHeaderlD 


Long 


Production or. stqiply order (e.g. pcec 1 
type 4 orders) 1 


25 


Cufl t omerResolut ion 


Text 


S for customer ship to; C for 1 
customer; G for customer group; M for R 
roar)cet; A for all customers H 




CustomerlD 


Text 


Customer identified with the place B 
Iceeping order B 


30 


ProductResolut ion 


Text 


P for product; G for product- grarxp: A 0 
for all products 




Product ID 


Text 


Product associated %rith the supply 
order 


35 


TimeReaolution 


Text 


D for day; W for wee)c; F for bi- 
weekly; M for monthly; B for bi- 
monthly; Q for quarterly; and A for 
annually. 




Calendar ID 


Long 


Pegged to a calendar | 


40 


DateCreated 


Date /Time 


Date the Supply Order Header was 
created/modified 


ScenarioData 


Boolean 


Yes if it is scenario data, No 
otherwise 




ScenarioCounter 


Byte 


Hundber of scenarios in «diich this 
header participates 


45 

Tes^rary Product List 

System table that contains a tenpox 


-ary product list 




1 Field Identifier | 


Field Type 




50 


1 ProductID 1 


Text 


^ 1 
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VMR Contract 

Data asaociated with a Vendor Managed Replawiahm^Tit Contract 



1 Field Identifier 


Field Type 


Description | 


1 VKRContractZD 


Text 


Identifier for the VMR Contract | 


fl ContracrtOate 


Date/Time 


u 

Date of the contract 


BxpirationDate 


Date /Time 


Expiration date of the contract 




Text 


Exanqole: Net-60, Het-30 


ProductResolution 


Text 


Product Resolution: P for Product, G 
for Product Group, A for all 




Text 


Product associated with the VMR n 
contract ^ 


TargetPilXRate 


Double 


Fill rate promised in the VMR 1 
contract H 


TuznAroundTime 


Double 


Nominal turnaround time | 


MinXnventoryFactor 


Double 


Minimum inventory factor agreed in ' n 
the VMR contract H 


Maxinventory Factor 


Double 


Maximum inventory factor agreed in | 
the VMR contract [| 


1 OrderRevisionFactor 


Double 


Customer's rights to revise order Q 


VMR Data 

Data associated trith 
identified in the hea 


Vendor Managed Replenishment for the customers 
der 


Field Identifier 


Field Type 


Description | 


VMRBeaderlD 


Long 


VMR Header Identifier 


OrderDate 


Date/Time 


Date when the VMR order data was 
entered 


PurchaseOrderlD 


Text 


Customer purchase order reference 1 


Orders tatus 


Text 


A for allocated; B for bacdcordered; R 


OrderQty 


Double 


Quantity associated with the order 


CuzoDe 1 iveryQty 


Double 


Quantity delivered against the order 
(cumulative measure) 


DueOate 


Date /Time 


Date when the order is planned to be 
delivered at the customer site 


DeliveredDate 


Date /Time 


Date when the order was actually 
received at the customer site 


ShipDate 


Date /Time 


Date «rtien the order is planned to be 
shipped 


LastShipmentDate 


Date/Time 


Date of the . latest shipment - made to 
fulfill an order 


ShipCarrier 


Date/Time 


The carrier used in delivering the 1 
order (to keep trade of the intransit R 
inventory) | 


LinkID 


Text 


Pegged to a defined s\zpply chain link H 
in the supply chain net«#ork table | 


FreightRateT2ibleID 


Text 


Based on transportation mode U 
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VHR Header 

Header file defining tlie Product X Customer X Time resolutions & vales for 
VMR 



Field Identifier 


Field Type 


Description 


VMRHeaderO 


Long 


VMR Header Identifier 


CustomerResolution 


Text 


Customer Resolution: S for Customer 
Shipto; C for Customer; 6 for Customer 
Group, A for all 


CustomerlD 


Text 


Should be a valid customer group or a 
null set (e.g.. Selling floor) 


ProductResolution 


Text 


Product Resolution: P for Product, 6 
for Product Oroiq), A for all 


Product ID 


Text 


Product covered by the VMR contract 


TimeResolut ion 


Text 


D for day; H for week; F for bi- 
weekly; M for monthly; B for bi- 

annually. 


Calendar ID 


Integer 


Pegged to a predefined calendar 


InventoryCont rol ID 


Text 


Pegged to inventory control parameters 
ID 


VMRCont ract ID 


Text 


Pegged to the VMR Contract table 


DateCreated 


Date /Time 


Date the VHR Header was 
created/modified 


ScenarioData 


Boolean 


Yes if it is scenario data. No | 
otherwise | 


ScenarioCounter 


Byte 


Number of scenarios in which this | 
header participates 1 
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i^>pendix B 

Database Specifications £or Equipment Repair Supply Chain 
The follcwixig are the specifications of the data tables for the equipment 
repair supply chain. 



10 



15 



20 



25 



30 



35 



40 



45 



50 



Equipment 

Information to classify equipment into gro\q>s. Tills information is 
relevant to Identify reliability characteristics of equipment parts. 



1 Field Identifier 


Field Description j| 


1 BquipmentID 


TZnlque Identifier for the equipment 1 


1 BquipmentLocation 


Location of the equipment R 


Inspect ionXocat ion 


Location ithi&re the equipment is 1 
Inspected/maintained | 


DateofMfg 


Tear of manufacture of equipment 1 




Total Cumulative running hours so far 1 


Region 


Region of reconnaissance atssociated with the 
equipment 


Characteristic 
(Identify) 


Other critical characteristic, e.g. , total running 
time 


etc. 




Repairable Item and CoiqMment Information 
Component 


1 Field Identifier 


Field Description 


Component ID 


Component ID in the BON 


Coii^>onentName 


name of the conqoonent 


MinPackQuantity 


Mlnimrum pack quantity 


PhysicalParameter 


Physical dimensions for the ctmipuiient 


CoarpCategory 


5 for Off-the-shelf; C for Customized 


H Packaging Instruct 
y ion 


Special packaging requirements 


BOM 

Engineering Bill of 
equipment to repair 


Material that describes the product structure from 
items to components. 


V Field Identifier 


Field Description 


BOMID 


IKnique identifier for the engineering BOH 


ParentType 


Type of the parent: Equipment/Repair Item/ Component 


ParentID 


Identifier of the parent (BquipmentID or RepairlteralD 
or CoiEponentID) 


1 ChildType 


Type of the child (Repair Item/Conpooent) 


1 ChlldID 


unique identifier for the child (Repair I temID or 
Component ID) | 


y Quantity 


Number of components used in parent | 
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Repairable Item 



Field Identifier 


Field Descripticm | 


Repair I temID 


nnique identifier of the repair item 


RepairltemName 


Etame/Description of the repair item 


PbysicalDimensicms 


Height X Depth X Hidth 


Height 


Height of the SOT 



Component Sxapplier 



Field Identifier 


Field Description 


CompSuppl ier ID 


Dhique identifier for the ccinponent sillier 


SupplierName 


Name of the component siqpplier 


PaymentTerms 


Rxas^le: Net-60 


StreetAddress 


Street Address 


StatelD 


Name of the State 


PostalCode 


Postal code 


Country 


tfame of the coimtry 



Supply Information 
Repair Time Matrix 

Aggregate matrix defining the repair rates for Repair Item X Repair 



Resource combinations 



Field Identifier 


Field Description | 


RepairMatrixID 


Identifier for the repair matrix | 


ResourceResolution 


Resoiirce resolution identifier 


Resource ID 


Okiique identifier for the repair resource 


RepairltemiD 


Uhique identifier for the repair item 


TimeResolution 


D for day; H for week; F for bi-weekly; M for 1 
monthly; B for bi-monthly; Q for quarterly; and A 
for axmually. 


ProcessTime 


Mean time to repair 


SetupMatrixID 


Identifier for the setup time matrix 
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Repair Sett^ Katrix 

Aggregate matrix def ining the sequence dependent setm times for 
item changeovers 



1 Field Identifier 


Field Description | 


H SetxipMatrixID 


Identifier for the Setup Matrix | 


1 PrevProductID 


Identifier of the repair item that has just been . | 
repaired [| 


1 NextProductn) 


Identifier of the repair item that needs to be 
repaired 


1 TimeResolution 


D for day; H for week; F for bi-%#eeJcly; K for 
monthly; B for bi-monthly; Q for quarterly; and A for 
annually. 


1 SetupTime 


Actual time to setup 



Repair Capacity Header 

Header file defining the Repair Resource X Time resolutions k values for 



20 



various Repair Capacity 


r Data 


Field Identifier 


Field Description 


RepairCapacityHeader 


Repair Capacity Header ID 


1 ResourceResolution 


Resource Group or Resource 


Resource ID 


Resource ID 


Capaci tyUni t 


Example, number of production hours, shifts, 
etc. (related to the time resolution) 


TimeResolution 


D for day; W for week; F for bi-weekly; M for 
monthly; B for bi-monthly; Q for quarterly; and 
A for annually. 


Calendar ID 


Pegged to a predefined calendar 


DateCreated 


Date when the aggregate repair plan was created 
(based on the time resolution) | 



35 

Repair Capacity Data 

Repair Capacity Data of the repair resource identified in the header 



H Field Identifier 


Field Description || 


1 RepairCapacityData 
B ID 


R^>air Capacity Data ID | 


1 TimePeriod 


Time period number jj 


H RepairCapacityHead 
II erID 


Repair Ca^city Header ID (See Repair Capacity || 
Header Table) Q 


45 n NoShif ts 


Number of planned shifts d^iring the time period 


1 LoadingFactor 


Planned loading rate (e*g. t utilization) | 


1 DowntimeFactor 


Projected downtime || 


1 CapacityRequired 


Capacity required | 


50 H 

H CapacxtyAvailable 


Capacity available ' 1 
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Repair Bstimatian H a ad er 

Header file defining the Item X Time resolutiona & values for various 



5 [ 


Field Identifier 


Field Description 


1 RepairBstHeaderlD 


Repair Estimation Header Identifier 


1 ARPID 


Identifier for an aggregate repair plan 


10 


ItemID 


Item associated with the production requirements 
plan 




TimeResolution 


D for day; W for wee)c; F for bi-wee)cly; M for 
monthly; B for bi-monthly; Q for quarterly; and A 
for annually. 


15 


Calendar ID 


Pegged to a predefined calendar 1 




1 DateCreated 


Date when the Repair Estimation plam was created 1 
(based on the time resolution) Q 


20 Repair Estimation Di 
Repair Estimation Di 


ita 

ita for the repair item identified in the header 




Field Identifier 


. J 

Field Description H 




RepairEstDatalD 


Repair Estimation Data ID 


25 


TimePeriod 


Time period number 




RepairEstHeaderlD 


Repair Estimation Header Identifier 




Quantity 


Number of units of production 


30 


ProposedChange 


Proposed change with respect to the quantity | 



Aggregate Repair Plan Header 

header file defining the Repair Item X Resource X Time resolutions & values 



35 


Field Identifier 


Field Description D 


H RepairPlanHeaderlD 


Repair Plan Data Series Identifier || 


1 RepairlD 


Identifier for an aggregate repair plan 1 


1 ResourceResoluticn 


Resource Resolution: R-Resource, 6-Group, N-Mode 1 


w 


ResourcelD 


Resource associated with the repair plan i 




RepairltemResolution 


Repair Item Resolution: P-Repair Item, G-Grbup | 




RepairltemID 


Repair Item associated with the repair plan | 


45 


TimeResolut ion 


D for day; W for week; F for bi-weekly; M for 
monthly; B for bi-monthly; Q for quarterly; and A 
for annually. 




Calendar ID 


Pegged to a predefined calendar 


50 


DateCreated 


Date %rtien the aggregate production plan was 
created (based on the time resolution) 
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Aggxegate Repair Plan Data 

Data related to the aggregate repair plan for the repair Item Identified In 
the APP header 



1 Field Identifier 


Field Description 


1 RepairPlanDataZD 


Identifier for the Repair Plan Data 


J TimePeriod 


Time period number 


1 RepalrPlanHeader 
ID 


Repair Plan Head identifier (see aggregate repair 
. plan Header table) 


Quantity 


number of units to be repaired 


PropoaedChange 


Recommended change in the planned quantity (to store 
changes between regeneration of Repair Plans) 


Component BstimatiOD Header 

Header file defining the Coiq>onent X Time values for various component 
requirement data 


i Field Identifier 


Field Description R 


1 CompBstHeaderlD 


Component Bstimatlon Header Identifier 


ComponentlD 


Component associated with an component estimation 
header 


BOMID 


Unique identifier for BOH 


DateCreated 


Date when the component estimation was created (based 
on the time resolution) 


TlmeResolutlon 


D for day; W for week; F for bi-wee)cly; M for 
monthly; B for bi-monthly; Q for quarterly; and A for 
annually. 


Calendar ID 


Pegged to a predefined calendar 


RepalrPlanID 


Pegged to an aggregate repair plain (if warranted) 


Component Estimatit 
Data related to re< 


yn Data 

niirements for the component identified in the header 


1 Field Identifier 


Field Description 


Con^EstDatalD 


Component Estimation Header ID (See Component 
Estimation Header Table) 


TimePeriod 


Time period number 


ComReq^aderlD 


Identifier for the component estimation header 


Quantity 


2luxid>er of units during the time period | 


Pr opos edChange 


Proposed Change In required quantity | 
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Material Delivery Schedule Header 

Header file defining the Conponent X Supplier X Time resoluticms £ values 
for various material delivery schedules 



Field Identifier 


Field Description |{ 


MDSHeaderZO 


Identifier for the Material Delivery Schedule | 
Header 1 


ComponentSupplyNode 
ID 


Identifier for component supply node 


SxipplierlD 


Siapplier associated with a Material Delivery 
Schedule 


TimeResolution 


D for day; N for week; P for bi-wee)ay; M for 
monthly; B for bi-monthly; Q for quarterly; and A 
for annually. 


CalexsdarlD 


Pegged to a predefined calendar 1 


DateCreated 


Date idien a Material Delivery Schedule i#as created | 
(based on consistent time units) 1 



Material Delivery Schedule Data 

Material Delivery Schedule for the Component identified in the header 



Field Identifier 


Field Description "^^"^^^^^^^^^^^^"^^^""^^^^^^ 


MDSDatalD 


Identifier for Material Delivery Schedule Data 


DeliveryDate 


Material Delivery Date 


MDSHeaderlD 


Identifier for the Material Delivery Schedule Header 


Quantity 


Number of tmits of material delivery 



Requirements Information 
Requirements History Header 

Header file defining Equipment X R^>air Item X Time resolutions & values 
for various demand histories 



Field Identifier 


Field Description 


ReqHistHeaderlD 


Identifier for a requirements history header 


RepairltemResolution 


y 

P for repair item; G for repair item Groiq>; A for 
all repair items 


RepairltemID 


Repair Item associated with requirements history 


EquipmentResolut ion 


C for Equipment; CG for ecjuipment group; A for 
all equipment 


Equipment ID 


Equipment (Groiq>) associated with requirements 
history 


TimeResolution 


D for day; W for week; P for bi-weekly; M for 
monthly; B for bi-monthly; Q for quarterly; and A 
for annually. 


Calendar ID 


Pegged to a predefined calendar \ 
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Requirements History Data 

Data for the demand history for the product defined in the header 



Field Identifier 


Field Description 


ReqHistDataZD 


Requirements History Data identifier (see 
Requirements History Header table) 




A xluc jpe£Xwu numoer 




Identifier for a requirements history header 




Kequirements Quantity | 


Equipment R^>air Oi 
Data for actual eqi 


rders 

lipment repair orders 


Field Identifier 


Field Description 


RepairOrderlD 


ID for the actual equipment repair order 


LineltemXD 


I^e item within the order 


Repa irOrderRe fNo 


Repair order identifier 


Equipment ID 


Equipment identified with the order 


RepairltemID 


Repair Item associated with the order 




Pegged to a calendar 


TimeResolution 


D for day; W for %fee)c; P for bi-wee)cly; M for 
raoncnxy; o ror Di-montniy; Q tor quarterly; and A for 
annually. 




Expressed in terms of the calendar and time 
resolution 


RequestedDate 


B3q>re8sed in terms of the calendar and time 
resolution 


DueDate 


Expressed in terms of the calendar and time 1 
resolution g 


ShipDate 


Esqpressed in terms of the calendar and time 1 
resolution H 


DeliveryDate 


Expressed in terms of the calendar and time 
resolution 


Quantity 


Quantity of the order 


Comments 


Such as value added services associated with the 
order 
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Future Requirements Header 

Header file defining the Customer X Product X Time resolutions & values for 
varioxis future requirements 



5 



1 Field Identifier 


Field Description 


FutureReqHeaderlD 


Future Requir«itents Header Identifier 


RepairZteffiResolution 


P for Repair Item, G for Repair Item Gro\q>, A 
for all Repair Items 


Repair I temID 


Repair Item (Group) associated with forecast 


EquipmentResolution 


C for Equipment, C6 for equipment group; A for 
all equipment 


EcfuimnonliTP 


Bt^uAjinwuw wxuu^i aoowwxawCu WitA £^cqujkrducubB 

history 


TimeResolution 


D for day; W for week; F for bi-weekly; M for 
monthly; B for bi-monthly; Q for quarterly; and 
A for annually. 


Calendar ID 


Pegged to a predefined calendar 


DateCreated 


Date when the forecast was created (based on the 
tinw resolution) 


1 FutReqType 


B for bottom-up; T for top-down 


1 BstimationAssumptions 


Asstimptions aissociated with the estimation 


1 BstimateOwner 


Author of the future requirements 



Future Requirements Data 

Data associated with the future requirements for the equipment -repair items 
identified in the header 



r Field Identifier 


Field Description | 


FutureReqDatalD 


Future requirements data series identifier | 


TimePeriod 


Time period number f 


FutureReqHeaderlD 


Pegged to the Future Requirements Header Table 


BstimateValue 


Future requirements data valuie 


BstiroateCV 


Coefficient of variation of estimate 
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Activity Header 

Header file defining the Equipment Group X Repair Item X Time resolutions & 
values for vario^la Activity data 



1 Field Identifier 


Field Description . 


1 ActivityHeaderlD 


Identifier for the Activity Header 


i BqxxipmentResolution 


Equipment Group Resolution: C for Equipment, G 
for Equipment Group, A for all 


Equipment ID 


ID Of the equipment eissociated with the activity I 


Repair I temResolut ion 


Repair Item Resolution: P for Repair Item, G for | 
Repair Item Group, A for all -| 


Repair I temID 


Repair Item associated with the activity Data | 


TimeResolution 


D for day; W for %ieek; P for bi-weekly; M for 1 
monthly; B for bi-monthly; Q for quarterly; and A I 
for annually. | 


Calendar ID 


Pegged to a specific rnlendnr I 


ActivityType 


Company wide, location level, etc. 1 


ActivityClass 


Activity class | 


Act i vi tyint ens i ty 


Intensity of the activity (low, medium, high) | 


ActivityShapelD 


Intensity of the activity (low, medium, high) fi 



Activity Data 

Data related to past and future activities for the equipment 



1 Field Identifier 


Field Description 


1 ActxvityDatalD 


Activity Data Series Identifier 


1 TimePeriod 


Timer period number (beginning of the time period) 


1 ActivityHeaderlD 


Activity Header Identifier 


ActivityDuration 


Time duration for the activity 


Pre- 

evaluat ionOty 


Estimate before the activity for the quantity due to R 
the activity | 


Post- 

evaluationQty 


Estimate after the activity for the quantity due to 1 
the activity | 
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Inventory Information 
Inventory Header 

Header file defining the Repair Item X Time resolutions & values for 
various inventory data 



Field Identifier 


Field Description "sa^^^^^^^^ 


InventoryHeaderlD 


Inventory Data Series Identifier 


Invent oryNode ID 


Identifier for an inventory logic warehouse 


InventoryControl ID 


Identifier for inventory control parameters 


ItemResolution 


Item Resolution: C for Component, P for Product, 6 
for Product Group and A for All 


RepairltemID 


Repair Item ID 


TimeResolution 


D for day; W for week; F for bi-weekly; M for 
monthly; B for bi-monthly; Q for quarterly; and A 
for annually. I 


Ca I ftTidar TP 


Pegged to a predefined calendar 1 


NinlnventoryLevel 


Minimum inventory level for the item 1 


MaxInventoryLevel 


Maximum inventory level for .the item | 


Inventory Data 
xnvencory uaua £ox^ h 


^^OMB xucxiu 1 L icsu ui WOP iictimsx 


Field Identifier 


Fxela Description l| 


inventoryDat a ID 


Inventory data identifier (see Inventory Header 
table) 


TimePeriod 


Time period number 


InventoryHeaderlD 


Inventory Data Series Identifier 


OnHandlnventory 


On-hand available inventory for allocation 


OnOrder Inventory 


On- order inventory 


BackOrderlnventory 


Back -ordered inventory 


InTransit 


In-transit qpiantity 


Reservedlnventory 

H 


Reserved inventory on-hand but available for 
allocation only in case of emergency 
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Inventory Parameters 

I>ata for the inventory control parameters 



Field Identifier 


Field Description || 


Invent oryControl ID 


Identifier for inventory control parameters: Assume 

4 w vi^Ti ^pyv nl annlTwrnS Ttvam^nw e*e\n^i^f\1 








1 


Poiicyrype 


roxicy cype: oo* nxn/nax, v^* ecc. 


MinlnventoryFactor 


Minimum inventory factor (e.g., in terms of weeks 
of sales) 


MaxInventoryFactor 


Maximum inventory factor (e.g., in terms of weeks 
of sales) 


MinOrderOtyPactor 


Minimum order quantity factor 


CarryChargeFactor 


Carrying cost factor 


OrderCbargePactor 


Ordering cost factor 


InventoryClass 


Inventory classification 


ReplenishroentFrequ 
ency 


Frequency of replenishment w.r.t. the time 
resolution in the header 



25 

Repair Resource Information 

Inf oinnation related to the repetir technician and test equipment 
Repair Resource 



Data related to rei 


>air resource 


1 Field Identifier 


Field Description | 


1 RepairResID 


Unique identifier for a repair resource (e.g., FAIG) 1 


RepairResMame 


Descriptive name B 


RepairResGroupID 


Repair resource group this resource belongs to | 


MaxLineRate 


Maximum line rate H 


MoWor)cstations 


Number of %»orkstations | 



40 Repair Resource Groiq> 

Data related to production resource grcnxp 



Field Identifier 


Field Description 


RepairRes(3ro\qpID 


unique identifier for the repair resource group 
(e.g., Plant4) 


RepairResGroupHamp 


Descriptive name 


RepairNodelD 


Repair node this group belongs to 


Attributel 


Attribute (e.g.. Category, Location) 


Attribute2 


Attribute (e.g.. Category, Location) 


Attributes 


Attribute (e.g.. Category, location) | 
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i^pendix C 

Interim Design Docximentation for the System Integrator 
of the Supply Frame Chain Hanager 

Class name: 

FrameManager 

Category: Supply Frame Chain Manager 
Documentation : 

This is a singleton class. It is running on the server. 
It has to be started before a client can start and make 
connection to it- The FrcuneManager is responsible to 
facilitate the integration of the client side of the 
system (the User Interface 18) with the server side of 
the system where the mathematical Model Engines and the 
DSS 10 database reside. The Fram^lanager is composed of 
a ClientManager, a ServerManager, a collection of 
Request Interpreter and objects which form the Functional 
Integrator 312. When a client program start up, it will 
connect to the FrameManager (obtain the object reference 
of the FrameManager) and call the initialization 
function. As part of the initialization of the client 
with the FrameManager, a Request Interpreter object will 
be created, inserted into the collection and the object 
reference will be return bac)c to the client. The client 
will also be registered with the ClientManager object of 
the FrameManager. The initialization also includes the 
user authentication. 
Export Control rPxiblic 
Cardinality : 1 
Hierarchy : 
Superclasses : none 
Associations : 

<no rolename> : ClientManager in association 
<no rolename> : Request Interpreter in 

association 

<no rolename> : ServerManager in association 
Public Interface: 
Operations : 

FrameManager 
ini t ial izeCl ient 

Private Interface: 
Attributes : 

mClientManager : ClientManager 
mServerManager : ServerManager 
mRequest Interpreter : 

List <Request Interpreter > 

A linked list of 
Request Interpreter , Each Request Interpreter will run in a 
separate thread or a separate process. This way, requests from 
multiple clients can be handled concurrently. 
State machine: No 
Concurrency : Sequential 
Persistence : Transient 
• Operation name: 
FrameManager 
Public member of : FrameManager 
Arguments : 

char* f raraeMgrConf igFi le 
Dociimentation : 

This is the constructor is the FrameManager. At the 
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construction time, it will read in the configuration 
information from a file ("f rameMgrConf igFile") . The 
information include things such as the name of the DBS 
Database and on which host it is running, where are the Model 
Engines (installed on which machines) , how many number of 
simultaneous client axe allowed to connect to the 
FrameManager, etc. The constructor is also responsible to 
initialize all other data member of this class. 

Concurrency : Sequential 

Operation name: 

initializeClient 

Public member of : FrameManager 

Return Class: Request Interpreter& 

Arguments : 

char*userName 

cbar*hostName 

char^password 

NotifyMsgtnotifyMsg 
Documentation : 

Once the client program has steurted and obtained the 
object reference of the FrameManager, it will call this 
function to initial itself with the FrameManager. It will 
pass in. the user name, password, host name, etc. The 
information will be used for authentication and registering 
with the ClientManager. The object reference of a NotifyMsg on 
the client side will pass in. This object reference will be 
used to notify the client about its request when it make an 
asynchronoxis request. (Asynchronous request will be allowed 
when the client request to run some of the strategic decision 
model . ) 

This function will return the object reference or a 
Request Interpreter through which the client will make all its 
requests . 

Concurrency : Sequential 

Class name: 

ClientManager 

Category : Supply Frame Chain Manager 

Docvunentation : 

Manage eind monitor the client coimection. Implement 
client connection policy, such as "after certain period of 
inactive time disconnect the client", "the total number of 
client connection can not exceed certain number". Also 
resposible to delete the corresponding Request Interpreter 
object after a client is disconnected (in such case as the 
client machine goes down, or the network connection is lost) . 

Export Control: Public 

Cardinality:! 

Hierarchy : 

Superclasses : none 

Associations : 

<ho rolename> : FrameManager in association 

Public Interface: 

Operations: 

registerClient 
mai t a inCl lent 

Private Interface: 
Attributes : 

clients : List<Client> 

A linked list of Client. The 
Client class contain the basic information about the' client, 
such as, the \iser name, the. client host name, the 
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corresponding Request Interpreter, time of initial connection, 
time of last request, pending requests, etc. 

State machine: No 

Conciirrency .-Sequential 

Persistence : Transient 

Operation name: 

registerClient 

Public member of rClientManager 

Retvim Class rbool 

Arguments : 

Client&aClient 
Documentation : 

Add a client to the client list. Enforce the relevant 
FrameManager policy such as the maximum number of simultaneous 
client . 

Concurrency : Sequential 
Operation name: 

maitainClient 
Public member of : ClientNanager 
Documentation: 

This function will be called periodically from the 
FrameManager. Within the fimction, each client will be 
checked to see if it needs to be disconnected. If a client 
needs to be disconnected, it will be removed from the list and 
the corresponding Request Interpreter object will be deleted. 
Concurrency : Sequential 
Class name: 

Request Interpreter 
Category: Supply Frame Chain Manager 
Documentation : 

This is the object the client is normally interact 
with. Each object of this type has to run in its own thread or 
process so that multiple client can request server services 
concurrently . 

Export Control : Public 
Cardinality :n 
Hierarchy: 

Superclasses :none 
Associations : 

<no rolename> : FrameManager in association 
Public Interface: 
Operations: 

request 

Private Interface: 
Attributes : 
theClient : Client* 

Reference to the client with whom this 
Interpreter is associated. 
State machine: No 
Concurrency : Sequential 
Persistence : Transient 
Operation name: 
request 

Public member of : Request Interpreter 

Return Class :bool 

Arguments: 

longscenar io ID 
longdomainID 
longrequest ID 
boolasynch 
long&resultID 
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Documentation: 

This function will be called by the client to maXe a 
request to perform certain task by the server (s) . The 
scenarioID and doroainID will identify the data associated with 
the request. The requestID will identify what kind of action 
need to be performed (by looking up a table within the 
system). If the request is not asynchronous ("asynch" false") 
the result will be retiimed immediately through the value of 
resiiltlD. The client can retrieve the actual data from the 
DSS Database through the re suit ID in the tcd^le associated with 
that type of recjuest. If the request of aynchronous, the 

result will be sent to the client later by calling the 
NotifyMsg object of the client. 

Concurrency : Sequential 

Class name: 

Serve rManager 

Category : Supply Frame Chain Manager 

Documentation : 

Manage the server connection. A server is a program 
(an object) from which we CcUi request specific service. For 
excunple, we may have a server being able to compute the 
optimal delivery frequency given the maximum inventory and 
service level constrain in a VMR setting. This is referred as 
Model Engine Server. A Model Engine Server can run on the 
same machine where the FrameManager is running, or it can run 
on different machine. Two Model Engine Servers of the same 
type can run on the same machine, or they Ccin run on different 
machines. The information governing the policy is stored in 
the FrameManager configuration file which was read in at the 
time of constructing the FrcuneManager . The Servei^lanager will 
enforce the policy such as on which machine to start which 
server, load balancing, etc. The ServerManager is also 
responsible to shutdown the servers when they are not needed. 

Export Control : Public 

Cardinality:! 

Hierarchy: 

Superclasses : none 

Associations : 

<no rolename> : FraimeManager in association 

Public Interface: 

Operations: 

addServer 

raaintainServer 

getServer 

Private Interface: 
Attributes : 

servers : List<Server> 

A linked list of Server 
object. A Server is a class which record the basic information 
about a server, such as name, type, which host it is running 
on, status, etc. 

State machine: No 
Concurrency : Sequential 
Persistence : Transient 
Operation name: 
addServer 
Public member of : ServerManager 
Return Class :bool 
Arguments : 

char* aServer 
Documentation : 
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Try to start a new server of certain type and add it 
to the server list. Here some of the server management policy 
will be enforced. For example, we may have a policy says that 
there should be no more than x number of Linear Programming 
servers in the entire system. Or we may have emother policy 
says that we cam not put more than x number of servers (of all 
types) on machine A. When the function is called only the name 
(type) of the server is passed in. Which machine the server 
should be on is determined within this function. 

Concurrency : Sequent ial 

Operation name: 

maintalnServer 

Public member of : ServerManager 

Documentation : 

This function is periodically called from 
FrameManager. It will check each server to see if any one 
needs to be shutdown. 

Concurrency : Sequent ial 

Operation name: 
getServer 

Public member of : ServerManager 

Return Class :Server& 

Arguments : 

char*aServer 
Documentation : 

Return a server of the specified type. It first 
check the server list to see if any one of that type is idle. 
If it is, it return the reference to that one and update the 
status. If not, it will call the addServer f\inction to try to 
add one. 

Concurrency : Sequent ial 



Claims 

1. A decisk>nsi43port system, comprising: 

decision support frames providing a view into a supply chain; 

a model engine comprising modeling processes analyzing the chain; and 

a frame manager managing the execution of the nxxieling processes to provide information for said frames. 

2. A system as recited in daim 1 , further comprising a database management system supplying datak)ase information 
to the nrxxleling processes and said frame manager. 

3. A system as recited in daim 1 . wherein said system conrprises a server mode indudng said engine and said man- 
ager arKl a client nrxxie comprising said frames. 

4. A system as recited in claim 1. wt^ein said datat>ase comprises an inventory data space, a supply data space and 
a demand data spaca 

5. A system as recited in daim 2. wherein said database includes a supply chain nei^^ 
ply node, a procbjction node, an inventory node and ademand node. 

6. A system ^recited in daim 1. wherein said nriodefirig processes conprise a cornponemprocuren^ 

opment module, a finished goods cfistritmtfon network design module, an aggregate production planning module, a 
finished goods inventory managentent module, a sales forecasting and planning module, a market data analysis 
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module and a vendor managed reptenshment mod ^' - - 

7. A system as recited in daim 1 , wherein said manager conrprises a system inte^ator and a functional integrator. 

8. A system as recited in daim 1 , wherein the supply chain indudes sales, inverrtory and production. 

9. A decision support system, comprising: 

dedsion support frames integrating analytical models of a supply chain responsive to a view point of a busi- 
ness process. 

10. A system as recited in daim 9, wherein said frames comprise a supply management frame, a demand manage- 
ment frame, a vendor managed replerdshmerrt frame, a planning, sales and inventory frame and a distrSxition net- 
work frama 

11. A system as redted in daim 10. further conprising a domain management process limiting data available to said 
frames responsive to a user selection. 

12. A system as redted in daim 9, further comprising a scenario management process providing scenarios for com- 
parison of management plans. 

13. A deepen support system, comprising: 

a demand and supply recorK^iliation process recondling production, sales and inventory. 

14. A system as recited in daim 13. wherein said process determines a feasbility capacity plan responsive to supply 
constraints. 

15. A system as recited in daim 13. wherein said process provides a verxJor replenishment plan responsive to pre- 
dicted sales and supply constraints. 

16. A system as redted in daim 15. wherein the plan considers production capacity, inventory and point-of-sale infor- 
matbn. 

1 7. A system as redted in daim 1 5. wherein the plan provides a strategic analysis using quantative models. 

18. A system as redted in daim 13. wherein said process recondles a top-down forecast with a bottom-up forecast. 

19. A system as redted in daim 18. wherein said bottom-up forecast indudes an expert based model. 

20. A storage media, comprising a recorK:aiation process recorv:ilir)g production, sales and inverrtory of a supply chain. 

21. A dedsion support system, comprising: 



a dient conprising: 

dedsion support frames providing a view into production, sales arxi inventory of a supply chain, said 
frames integrating analytical models of a sipply chain responsive to a view point of a business process, 
said frames corrprising a supply management frame, a demand management frame, a vendor managed 
replenishment frame, a planning, sales arxi irr^^entory frame and a cfistrbution network frame; and 

a server comprising: 

a model engine, corrprising: 

rrxxjeling processes analyzing the chain, said modeling processes comprising a component procure- 
ment policy devekpment module, a finished goods distrdxition network design modiJe. an aggregate 
production planning rnodule. a finished goods inventory rnariagernent rnodule. a sales fv 
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planning module, a mark^ data analysis module and a vendor managed replenishment module; and 

a demand and supply reconcOiation process recondBng productbn. sales and inv&itory by recondGng 

a top-down forecast with a bottom-up forecast Including an expert based model; 

a capacity process determining feasibility of a capacity plan responsive to supply constraints; 

a replen^hntent process providing a vendor replenishment plan responsive to predicted sales and 

supply constraints said process recondles a top-down forecast with a bottonhup forecast; 

a scenario management process providing scenarios for conrpar^n of managentent plans; 

a frame manage managing the execution of the modeling processes to provide information for said 

frames, said manager comprisirtg a system integrator and a functional integrator; 

a database management system supplying datattase information to ^le modeling processes and said 

frame manager; and 

a domain management process limiting data available to said frames responsive to a user selection. 
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DSS System Architecture in the Context cf Equipment Repair Supply Chains 



FIG. 2 



158 



EP0 770 967 A2 




The Data Spaces in Supply Chain Management 



FIG. 3 
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Supply Chain (nrormarion Systems 



Decision Support Thread 



FIG. 4 
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